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Preface 

lliis document describes the Mesa programming language. Its approach is tutorial and it is 
intended to be read somewhat as a textbook. It is neither a usefs guide nor a reference manual. 

llie Elements of Mesa Style, by James Morris, is a recommended supplement to this manual. The 
style manual contains several examples of well-constructed Mesa programs, with explanations of their 
development and commentary on using the language properly. Its purpose is to provide assistance 
in using the features of Mesa to write programs that work reliably and are easily maintained. 

Programmers. should also read the Mesa Users Handbook, which provides an introduction to tlie use 
of the Mesa system and a guide to other documentation. The Mesa System Documentation and 
Mesa Debugger Documentation describe facilities available in the Alto implementation of the Mesa 
programming system. These include input and output, which are done procedurally and are not 
built into the language. 

Suggestions, corrections and criticisms concerning the style and content of tliis manual are 
encouraged and should be sent to your support group. 
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CHAPTER 1, 



INTRODUCTION 



This manual concentrates on the Mesa programming language. Mesa is really a programming system 
of which the language is but one part. Other components of the system are documented separately, 
as are the details of preparing, compiling, debugging and running Mesa programs. 

Each chapter of this manual discusses some aspect of the language, using examples as well as 
descriptions of semantics and syntax. The chapters emphasize different language features and 
provide different levels of detail. The complete treatment of some features requires more than one 
chapter. Generally, earlier chapters introduce topics, and later ones supply additional detail. Titles 
of chapters, sections and subsections indicate the language issues with which they deal. 

In each major section, information is presented at three levels: 

(1) Ordinary usage (motivation, forms and semantics), frequently with examples. 

(2) Syntax equations (when appropriate). 

(3) Fine points (if applicable): restrictions, special cases, references to later material, precise 
semantics, etc. 

Level (1) is intended to offer a basic understanding of Mesa. Reading only first level material 
should be adequate to begin programming in the language. Levels (2) and (3) supply more detail 
and provide information about the full power of Mesa. 

As a rule, these levels of discourse occur separately and in the indicated order. A section with a 
heading followed by an asterisk (*) deals with specialized material that can be skimmed or skipped 
entirely on first reading. Occasionally, fine points or syntactic details are presented within first-level 
material. The reader will be able to distinguish between levels by their appearance. Fine points are 
written in a small font, like this. Syntax equations and syntactic categories appear in the following font: 
FontForSyntax. 

Any italicized word or phrase is important. If a Mesa technical term is being introduced, it will be in 
italics; if a term is used before being defined, it will be italicized to warn the reader that it should 
not be taken lightly and that it has a particular meaning in Mesa. Occurrences of a technical term, 
once defined, are not distinguished. Lastly, names appearing in programs are italicized in both the 
program text itself and the explanations of that text. 

Programming examples are indented relative to the surrounding text to distinguish them. 



Chapter 1: Introduction 



1.1. Syntax notation 



Mesa's grammar is described by syntax equations written using a variation of Backus-Naur Form (or 
BNf). For those unfamiliar with BNR an explanation follows. Reading and understanding that 
explanation is imperative for full use of this manual: in a first reading, details of the syntax 
equations can safely be skipped. Those familiar with BNF should scan this section to discover the 
particular variation being used. 

An individual syntax equation defines a portion of the Mesa grammar. It specifies a rule for 
forming some class of phrases in the language. A phrase class has a name, e.g.. Program, and is 
defined by one or more syntax equations. Phrase names are always printed in the syntax font when 
their use is meant to be technically accurate. For example, an OctalDigit, which can be any of 0, 
1, 2, . . ., 7, is defined by the equation: 

OctalDigit :: = 0| 1|2(3 |4|5 |6|7 

Each equation consists of a phrase name on the left, followed by the operator :: = (which should be 
pronounced "is defined to be"), in turn followed by a formation rule for that phrase class A 
formation rule consists of one or more alternatives, separted by the syntactic operator vertical bar, | 
(which should be pronounced "or"). The ordering of alternatives is not important. In the definition 
of OctalDigit, "3" is an alternative. 

Each alternative is a sequence of symbols, where a symbol is either a phrase name (in the syntax 
font) or a syntactic literal. In a syntax equation, a literal symbol stands for itself. The reserved 
words of Mesa, such as begin, appear as literals; they are always written using upper-case characters 
in the font shown. The digits 0, 1, 2, etc. and special characters, such as =, + and <-, also are used 
to form literal symbols. Some composite symbols are formed from more than one special character, 
e.g., =>. Spaces in syntax equations are used only to separate the items in the rules and have no 
special significance. 

The phrase name empty is often used as one of the alternatives in a formation rule. It means that 
the rule permits an "empty" phrase as one of its alternatives (i.e., an actual phrase is optional; it 
may or may not occur in the result of applying the formation rule). 

Comments embedded in syntax rules are preceded by a double dash, --, and appear to the right, e.g.. 

Digit ::= OctalDigit |8 1 9 -a decimal digit is an OctalDigit or 

an 8 or a 9 

Often, only part of the total definition of a phrase class is given. To indicate that there are other 
ways of forming phrases of that class, an ellipsis (...) is used as an alternative within the rule. The 
definition of Statement is distributed throughout much of the manual in this way. When a certain 
statement form, such as the AssignmentStmt, is being discussed, the following partial rule 
appears: 

Statement ::= AssignmentStmt | ... -this is just an example. 

One can read this as, "A Statement is defined to be an AssignmentStmt, among other things." 

Within a single alternative, the order of symbols is important. The alternative acts as a "template" 
for forming an actual phrase; literal names and literal characters are copied, while substitutions are 
made for the phrase names. Consider the_ following example: 

ReturnStmt ::= return | return Constructor 

("A ReturnStmt is defined to be return or return followed by a Constructor.") The second 
alternative means that return and some actual phrase defined by Constructor occur in exactly 
that order. 
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Syntax equations can indicate recursive substitution: for example: 

IdList ::= identifier | identifier , IdList 

In a Mesa program, an identifier is basically a name. This equation defines an IdList to be a list 
of one or more names, with commas separating them if there is more than a single name in the list. 

ITiis result is explained as follows. The formation rule for IdList consists of two alternative rules: 

Rule 1: (First alternative) "An IdList is defined to be an identifier", i.e.. any one name can replace an IdList. 

Rule 2: (Second alternative) "An IdList is defined to be an identifier followed by a comma followed by another 
IdList". i.e., name, IdList can replace an IdList. 

To derive a single name, use Rule 1 as shown below. (Note: The substitutions are emphasized by writing 
them in italics.) 

IdList :: = name (by Rule 1) 

To derive two names separated by a comma: 

IdList :: = name, IdList tby Rule 2) 

name, name (by Rule 1) 

To derive three names separated by commas: 

IdList ::= name, IdList (by Rule 2) 

name, name, IdList (by Rule 2) 
name, name, name (by Rule 1) 

To derive n names separated by commas, use Rule 2 n-1 times and then use Rule 1. 

The following syntax equation also relies on recursion: 

StmtSeries :: = empty [Statement | Statement ; StmtSeries 

The equation is read as, "A StmtSeries is defined to be empty, or a single statement, or a series of 
statements separated by semicolons; the last statement may be followed by a semicolon." 

A trailing semicolon is possible because: 

1) A StmtSeries may take the form specified by the third alternative, "Statement : StmtSeries". 

2) After some number of further substitutions using the third alternative, the recursive reference to StmtSeries 
may take the "empty" form, i.e., "... Statement : empty" 

3) empty is replaced by nothing at all i.e., "... Statement ;". 

Commas and semicolons are used as major separators for a variety of constructs in Mesa. To 
distinguish between such constructs, a convention is adopted that the suffix "List" on a phrase name 
implies a sequence separated by commas, while "Series" implies a sequence separated by 
semicolons. This convention is reflected by the phrase names IdList and StmtSeries above. 



CHAPTER 2. 



BASIC DATA TYPES AND EXPRESSIONS 



This chapter presents some of the fundamentals of Mesa. It discusses how to declare, initialize and 
assign values to variables. It also describes the basic types for numeric, character and Boolean data, 
as well as the operators used to construct expressions having these types. 

The Mesa language is strongly typed. The programmer is given a collection of predefined types and 
the ability to construct new ones; he is encouraged to choose or invent suitable types for each 
particular application. Every variable used in a Mesa program must be declared to have one of 
these types: every constant has a type; and every expression has a type derived from its components 
and context. All types can be deduced by static analysis of the program, and the language requires 
that each value be used in a way consistent with its type according to rules specified here and in 
chapter 3. The type of an object determines its representation and structure as well as the set of 
applicable operations. In addition, the type system can be used to partition the universe of objects 
and avoid confusion, even among classes of objects that are represented identically. 



2.1. A slice of Mesa code 

The example below is an excerpt from a Mesa program. It assigns to gcd the greatest common 
divisor (GCD) of a pair of integers, m and n (where m, n and gcd are integer variables in the 
program from which this excerpt was taken; we assume their values need not be preserved). The 
example uses the Euclidean Algorithm for finding the GCD of two numbers and works as follows: 

If bodi m and n are zero, the GCD is zero (by convention). 

Otherwise, repeat the following until n is zero: find the remainder of dividing m by /?; set m 
to the value of n\ then set n to the remainder. The final value of m is the GCD of the 
original m and n except that it may be negative; taking its absolute value gives the GCD. 

Example. Slice of Mesa Code Using the Euclidean Algorithm 

- Given are integers m and a?, which can be altered. (1) 

IF m-Q AND A? = THEN gcd ♦" " by convention (2) 

ELSE (3) 

BEGIN (4) 

r: integer; (5) 

UNTIL 77 = (6) 

DO (7) 

r ^ m MOD /]; - r gets remainder of m/n (8) 

m ^ n\ n ^ k " update variables (9) 

ENDLOOP; (10) 

gcd < — in case one of m or n was negative -- ABS[m]; (11) 

end; (12) 
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llic example contains twelve lines of source code, including comments, l^he numbers in parentheses 
at the right side are for reference only and are not part of die source code. Comments begin with 
die symbol "--" and terminate at line endings. They may also be completely embedded within lines, 
in which case they both begin and end with '*-". 

Line (2) begins an if statement that uses the values of m and // to select between two alternati\es. If 
boUi values are zero, the assignment statement following then is executed; it assigns the value to 
gcd (the character "^" is Mesas assignment operator). If either is nonzero, the assignment is 
skipped and the compound statement following else (lines (4) through (12) inclusive) is executed. 
(Distinguishing the two cases is actually unnecessary, but doing so illustrates more features of Mesa.) 

The second alternative is a block, a series of declarations followed by a series of statements, all 
bracketed by "begin" and "end". Line (5) declares a variable r of type integer for use within that 
block. A semicolon separates the declaration from the statements that follow it. 

The iteration in the algorithm is performed by the loop (until /7=0 do...endloop), which contains 
three embedded assignment statements. The loop repeats until ri is equal to zero. If it is zero at the 
outset, the embedded statements are not executed at all. Statements are separated by semicolons. A 
semicolon at the end of a statement series that is embedded in another statement (such as the series 
in the loop) is optional; it is permissible to write a semicolon after every' statement in the series. 

Within the loop, line (8) assigns to r the value of the expression "m mod n'\ which gives the 
remainder of dividing m by n. Line (9) updates m to contain the previous value of n and then 
updates // for the next iteration, if any. Control transfers from the end of the loop, line (10), back to 
line (6), where the new value of n is tested. If it is not zero, the loop is repeated; otherwise, 
execution continues with the first statement following the loop, line (II). 

When control reaches the assignment statement in line (II), m either has its original value (if n was 
zero) or contains the value n had just before it became zero. The expression "ABS[m]" has the form 
used for calling a function and passing it one or more arguments; square brackets enclose the 
argument list. Normal parentheses, "(" and ")", are used only for nested expressions, e.g., 
''a*(b+c/{d'-e)*J).'' The assignment places the absolute value of m into gcd\ this is the correct 
result. At this poinL the reader is urged to trace through the example with initial values for m and 
n of 15 and 12, respectively; the result should be gcd=i. 

2.1 J. Basic lexical stmcture 

The names gcd. m, n and r in the example are called identifiers. The general form of an 
identifier is given by the following (informal) syntax: 

An identifier is a sequence consisting of any mixture of upper-case letters, lower-case 
letters or digits, the first of which is a letter. Upper and lower case letters are different and 
do distinguish identifiers. 

The following, valid identifiers are all distinct: 

aBc Abe DiskCommandWord displayVector machl x32y40 

Identifiers consisting entirely of capital letters are reserved for use by the Mesa language. Some, 
such as IF, are punctuation symbols; others name built-in types, such as integer, or functions, such 
as ABS. All such words that have special meaning and are not to be defined by the programmer are 
called reseiyed \vords. It is legal for the programmer to use fully capitalized identifiers, but he risks a 
clash with a reserved word (possibly a new one in some future version of the language). To avoid 
this, at least one digit or lower case letter should appear in any identifier. Appendix E lists the 
current set of reserved words. 



6 Chapter 2: Basic Data Types and Expressions 

Mesa uses the blank (or space) character to separate basic lexical units of the language (such as 
reserved words and identifiers). Blanks are significant separators of lexical units. They may not be 
embedded in identifiers, composite symbols (such as > = ), or numeric literals (such as 1000). 
Blanks are meaningful in string constants (section 6.1.1), and there is a character constant for 
space (section 2.4.3). As a separator, any sequence of contiguous blanks is equivalent to a single 
blank. A 'I^AB character also behaves exactly as a blank when used as a separator. 

A carriage-return character behaves as a blank for separating lexical units also, but it has one extra 
function: if the last part of a line is a comment, the carriage return acts as the teiininator of that 
comment. Thus, multiline comments (those containing carriage returns) must begin with "--" on 
each new line. IJne breaks have no significance as statement separators. For example, the single 
loop statement in the example extends over a number of lines, and a semicolon is used to separate 
two statements in a series. 

Semicolons are used for separating declarations, for separating a series of declarations from following 
statements, and for separating statements in a series from one another. They cannot be used with 
abandon, however: care is necessary when writings statements {sec. 4.2.1) or SELECT statements (sec. 
4.3.1). Multiple statements can be written on a single line, separated by semicolons. 



2.2. Simple declarations 

The example (Euclidean Algorithm) contains the following declaration: 
r; integer; 

This declares r to be a variable of type integer (sec. 2.4.1), one of Mesa's built-in types. More than 
one variable can be declared at the same time. For instance, 

Xr y, divisor: \H1EGER\ 

declares identifiers x y and divisor as variables of type integer. These examples reflect the two 
primary purposes of every declarauon: 

to designate one or more identifiers as variables, and 

to specify their type. 

A declaration always begins with a single identifier or a list of identifiers. Conventionally, "list" is 
used to denote a single item as well as multiple items separated by commas. An identifier list 
(IdList) is defined as follows: 

IdList :: = identifier | 

identifier, IdList 

A declaration begins with an IdList followed by a colon. The colon is followed by a type 
specification (integer, for instance, is a type specification). 

2.3. The fundamental operations: assignment, equality and inequality 

The example contains the following five assignment statements: 

gcd ^ 

r ♦" mhAOD n 

m^ n 

n ^ r 

gcd ^ ABS[m] 
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An assignment statement has the following svntax: 



AssignmentStmt 

Leftside 

RightSide 



Leftside ^ RightSide |. .. 

identifier | . . . -- plus forms for array indexing, etc. 

Expression 



TTie RightSide may be any expression (section 2.5) provided that its type confowis to that of the 
Leftside. "Conforms" is defined in section 2.4.6 and is discussed further in section 3.5: for now, it 
can be taken to mean: "is tlie same as." The LeftSide may be a simple variable or a component of 
an aggregate variable (such as an element of an array). In any event, a LeftSide denotes a variable, 
sometliing capable of receiving values. A LeftSide cannot, for example, be a constant, while a 
RightSide can. 

The assignment operation (<-), the equality operation ( = ) and the inequality operation (#) are 
called the fundamental operations. They can be apphed to values of most types (including, for 
instance, entire arrays). The rules governing which pairs of operands may be used in a fundamental 
operation are detailed in section 3.5. 



2.4. Basic types 

The types of variables in a Mesa program fall into two broad classifications, built-in types and user- 
defined types. Chapter 3 describes how a programmer can define new data types using type 
constmctors. This section discusses the basic, built-in types. These include several numeric types 

(INTEGER, LONG INTEGER, CARDINAL, LONG CARDINAL arid REAL), a type for logical values (BOOLEAN), 

and a type for individual character values (character). The built-in type string (for sequences of 
characters) is described in chapter 6. 

2J.1. The numeric types integer and cardinal 

Mesa provides two standard numeric types, one with values ranging over the signed integers: the 
other, over die unsigned integers. Neither type completely mirrors the corresponding mathematical 
abstraction (the integers Z or the natural numbers N, respectively) because a finite representation is 
used for values of each type. The range of the type integer is (approximately) symmetric about 
zero, and values of type integer are represented as signed numbers. The range of the type 
cardinal is some finite interval of the natural numbers that includes zero, and values of type 
cardinal are represented as unsigned numbers. "Signed" and "unsigned" are not types: rather, they 
describe the machine representation of a numeric value. 

The programmer must choose an appropriate type for each numeric variable, cardinals offer a 
somewhat greater positive range than integers, and this is significant in a few apphcations, e.g., 
those that manipulate addresses that might be the same size as the word size. More importandy, 
declaring a variable to have type cardinal asserts diat its value is always nonnegative: the compiler 
can use such assertions to perform more checking and to generate better code. Programmers are 
encouraged to declare as much information about each variable as possible: the ranges of numeric 
variables can be further constrained by using subrange types (section 3.1.2). 

The types integer and cardinal are distinct and not interchangable. They are, however, closely 
related. Mesa allows most combinations of these types to occur within assignments and arithmetic 
expressions (but not relational expressions). Care is necessary to avoid ambiguity and failures of 
representation when values with different representations are mixed. This is discussed further in 
sections 2.4.6 and 2.5.1.1. 
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2.4. 1. L Numeric literals 

A numeric literal is an instance of the phrase class number, defined as follows: 

A number is a sequence of digits. The digits may optionally be followed by the letter B or 
D. which in turn may optionally be followed by anotlier sequence of digits denoting a scale 
factor. No spaces are allowed within numeric literals. 

If D is specified explicitly, or if neither B nor D appears, the number is treated as deeimal. ITie 
letter B means the number is octal (radix 8). A scale factor indicates the number of zeros to be 
appended to die first sequence of digits; the scale factor itself is always a decimal number. ITie 
literals below all denote the same value: 

6400 6400D 64D2 14400B 144B2 

A numeric literal always denotes a nonnegative number (i.e., ~5 is considered to be an expression in 
which the unary negauon operator is applied to the literal 5 to produce an integer value). To be 
valid in a context requiring a cardinal, the value of the literal must be a valid cardinal number. 
Similarly, if an integer is required by context, the value must be a valid (posiuve) integer. (See 
section 2.4.4 for more details) 

2.4.2. Type BOOLEAN 

A BOOLEAN value can be either true or false, and these are the only literals of type boolean; i.e., 
BooleanLiteral :: = false [true 

boolean expressions are used in conditional statements (following if) and in certain loop constructs. 
For instance, the following skeletal form describes the flow of control in Example 1: 

IF W=0 AND n = THEN . . . 

else 

UNTIL /2 = 
DO 

ENDLOOP; 

The expression "/? = 0" is a boolean expression: its value is true if die value of n is zero and false 
odierwise. The expression 'V?7=0 and /i=0" is also a boolean expression; its value is true just if 
both relauons are. The relational and logical operators discussed in sections 2.5.2 and 2.5.3 all yield 
BOOLEAN values. 

Variables of type boolean can be assigned values and appear as operands (although not of 
arithmetic operators) just as any other Mesa variables. For example, the above program outline 
could validly be replaced by the following: 

mIsZero, nIsZero: BOOLEAN; 

mIsZero ^ (m = 0); nIsZero ^ a? = 0; -- compute whether m and n are zero 
IF mIsZero AND nIsZero then ... 

ELSE 

UNTIL nIsZero=i^\JE -- equivalent to just nIsZero by itself 

DO 

nIsZero ♦- /? = 0; -- recompute whether /; is zero just before testing 

ENDLOOP ; 
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2.4.3. Type CHARACTER 



A value of type character represents a single character of text, character values are ordered 
(according to the order specified in appendix C) and can be compared using the normal arithmetic 
relations, character values are distinct from numbers, and they cannot be assigned to variables 
with numeric types. Limited aritlimetic is, however, allowed on characters (section 2.5.1.2). 

A characterLlteral is written as an apostrophe C) immediately followed by a single character 
(which can be a blank, carriage-return, semicolon, apostrophe, or any other character) or as an octal 
number followed by C. For example: 

lowerCaseA <- 'a; 

?7iark ^ ' ; - mark is set to be a blank. Here a blank is significant 

endMarker <- '; ; -- endMarker is set to be a semicolon 

asciiCR *- 15C; - an Ascii Carriage /ieturn character: 

2,4 J. The numeric types LONG INTEGER and LONG CARDINAL * 

For some applications, the ranges of the numeric types introduced in section 2.4.1 are too limited. 
Mesa provides both a predefined type long integer, with signed representation, and a predefined 
type long cardinal, with unsigned representation, for such applications. These types offer greater 
ranges, but their values occupy more storage and are generally more time-consuming to manipulate 
than those of the previously introduced numeric types. 

In an implementation, values of types integer and cardinal are expected to be represented by 
single machine words, while values of types long integer and long cardinal are expected to 
occupy two words. For this reason, integer and cardinal will be referred to as short numeric 
types: long integer and long cardinal, as long numeric types. On a machine using two's 
complement arithmetic and a word length of N bits, the following table indicates the range spanned 
by each numeric type (*'.." replaces the mathematician's comma in this interval notation): 



integer 


[^2^v-i ^^ 2^^-l) 


CARDINAL 


[0 .. 2^^) 


LONG INTEGER 


r 22A'-1 2^^"^) 


LONG CARDINAL 


[0 .. 2^^^) 



'^The actual ranges for these types are given in appendix C, the machine dependencies appendix. 

Long numeric constants are denoted by numeric literals defined by the phrase class number 
(section 2.4.1.1). The allowable type of any decimal or octal literal is detennined by its value, as 
summarized by the following table (using the conventions introduced in the preceding paragraph): 

Range Allowable Types 

[0 .. 2^'^) INTEGER, CARDINAL, LONG INTEGER, LONG CARDINAL 

[2^^''^ .. 2''^') CARDINAL, LONG INTEGER, LONG CARDINAL 

[2^ .. 2^^"^) LONG INTEGER, LONG CARDINAL 

^22N'l ^^ 2^^) LONG CARDINAL 

As in the case of short numeric types, the types long integer and long cardinal are distinct but 
closely related. Mesa allows most combinations of these types and the types integer and cardinal 
to occur within assignments, arithmetic expressions and relational expressions, but care is necessary 
when this is done (see sections 2.4.6 and 2.5.1.1). 
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14,5, Type REAL (interim) * 

llic values of Mesa's type real are approximations of mathematical real numbers. These 
approximations are sometimes called floating-point numbers. For the current version of Mesa, a 
standard representation for floating-point values has not been chosen. 'ITie language nevertheless 
provides some help with floating-point computation. It allows declaration and assignment of real 
values, and real expressions constructed using the standard infix operators are converted to 
sequences of procedure applications by the compiler. 

A REAL value is assumed to occupy the same amount of storage as a long integer (i.e., two words). 
Beyond this, no assumptions are made about the representation of reals. There are no literals with 
type real. Users of real arithmetic must provide an appropriate set of procedures for performing 
the arithmetic and relational operations. 

Although Mesa provides no denotations of real literals, it does provide automatic conversion from 

INTEGER, LONG INTEGER, CARDINAL Or LONG CARDINAL tO REAL (seCtion 2.4.6). ThuS numbers 

(numeric literals) can appear in real expressions and provide denotations of certain real constants. 

2.4,6, Relations among basic types * 

If two types are completely interchangable, they are said to be equivalent, A value having a given 
type is acceptable in any context requiring a value of any other type equivalent to it; there is no 
operational difference between two equivalent types. None of the basic types discussed in section 
2.4 is equivalent to another basic type. 

One type is said to conform to another if any value of the first type can be assigned to a variable of 
the second type. A type trivially conforms to itself or to any type equivalent to itself. In more 
interesting cases, an automatic application of a conversion function may be required prior to the 
assignment. Conformance and its implications are discussed further in section 3.5. 

There are non trivial conformance relations involving the types integer, long integer, cardinal, 
LONG cardinal and real. These relations allow certain combinations of the numeric types to be 
mixed, not only in assignments but also in arithmetic and relational operations (section 2.5). They 
also permit these types to share denotations of constants (section 2.4.4). The conformance relations 
can be summarized as follows: 

INTEGER and CARDINAL conform to integer. 

integer and cardinal conform to cardinal. 

INTEGER, LONG INTEGER, CARDINAL and LONG CARDINAL COnform tO LONG INTEGER. 
INTEGER, LONG INTEGER, CARDINAL and LONG CARDINAL COnform tO LONG CARDINAL. 
INTEGER, LONG INTEGER, CARDINAL, LONG CARDINAL and REAL COnfomi tO REAL. 

Pairs of numeric types not on this list do not conform; e.g., it is not possible to assign a long 

INTEGER to an INTEGER Or a REAL tO a CARDINAL. 

Particular care is required when numeric types with different representations are intermixed. 
Mathematically, Z D tV; however, it is not necessarily true that integer D cardinal or that long 
INTEGER D LONG CARDINAL. For instance, with the assumptions above, the intersection of integer 
and cardinal is [0..2^^"-^). Within this interval, the signed and unsigned representations agree, and 
the interpretation of a short numeric value is unambiguous. If a cardinal value lies in this range, it 
can validly be assigned to an integer variable, and vice-versa: outside this range, the value represented 
by a given word depends upon whether it is viewed as a cardinal or as an INTEGER. Similar 
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considerations apply to long cardinal and long integer. 

Hxample: 

Witli the assumptions above and yv=16, the unsigned value 177777B and the signed value -1 
are encoded by die same bit pattern. 

Assignment of an unsigned value to an integer variable, or of a signed value to a cardinal 
variable, implicitly invokes a conversion function, which is just an assertion that the value to be 
assigned is an element of cardinal Pi integer. // is the responsibility of the programmer to ensure 
that the conversion is valid. In many cases this is not too difficult, but programmers are urged to 
avoid mixing signed and unsigned representations w^hen this is possible. It almost always is. 

Mesa does guarantee that long T D T for any type T and that long integer D cardinal; thus it 
is always valid to assign a short numeric value to a long integer variable or a short unsigned value 
to a LONG cardinal variable. The properties of conversion to type real are not specified by the 
language. 

Some fine points: 

A user supplied procedure FLOAT is automatically applied to convert a value from type LONG INTEGER to 
REAL. Short numeric values are converted first to LONG INTEGER and then to REAL. 

Conversion from a short numeric value to a LONG INTEGER (and thus to a REAL) is substantially more 
efficient when the value has an unsigned representation. 

The conversion of a constant to type REAL occurs every time the containing expression is evaluated at run-time. 

Neither boolean nor character conforms to any other basic type. 

Examples: 

/.• integer; /?; cardinal; //.• long integer; x: real; 



(valid) 


/ ^ 0; 
// *- 0; 




X *- /?; 




X *- ii\ 


(invalid) 


i *- x: 
n ^ true; 


2.5. Expressions 





Expressions are constructs describing rules of computation for evaluating variables and for generating 
new values by the application of operators. The overall syntactic rule for an expression is given by 

Expression :: = Disjunction | AssignmentExpr | IfExpr | SelectExpr | . . . 

The Disjunction form includes all the numeric operations, relational operations, and boolean 
(logical) operations and is discussed in this section. An AssignmentExpr allows one to write 
multiple assignments in a single statement and is discussed in section 2.5.4. The IfExpr and 
SelectExpr forms are discussed in chapter 4. 

The basic unit from which expressions are built is called a Primary. This syntactic class includes 
references to variables, literals, fimction calls (chapter 5), and any arbitrary expressions embedded in 
parentheses: 
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Primary ::= Variable | Literal |( Expression )| FunctionCall |. . . 

Variable ::= Leftside 

Literal ::= number | BooleanLiteral |characterLiteral 

FunctionCall :: = BuiltinCall | Call - defined in chapters 

Recall tliat every expression has a well-defined type in Mesa. The general rules for determining tlie 
type of an expression from tlie types of its constituent parts are given in section 3.5. hi this section, 
the types of the basic expression forms (as functions of the types of their operands) will be outlined. 
For example, the type of a Primary is the type of the Variable or Literal involved, or reduces to 
the type of the Expression within parentheses, or is the type of the value returned by the 
BuiltinCall (some of which are defined below) or the Call of a user-defined procedure (section 
5.1). 

A Primary can be of almost any type; this is not true of most of the expression forms built up 
using Mesa s operators. Some operators are numeric and some are boolean. The next sections 
discuss the numeric operations, the relational operations, and the operations applicable only to 
BOOLEAN values. Considered together, the operators form a single hierarchy with respect to their 
precedence, which is described with each operator class and summarized in section 2.5.5. 

25.7. Numeric operators 

The operations on numeric values are addition, subtraction, multiplication, division, modulus, and 
arithmetic negation. The syntax for this group of operations is 



Factor 

Product 

MultiptyingOperator 

Sum 

AddingOperator 



: = Primary | - Primary - negation 

: = Factor | Product MultiplyingOperator Factor 

: = * I / I MOD 

:= Product I Sum AddingOperator Product 

:= +1- 



These operators have their usual mathematical meanings. The division operation on integers, /, 
always truncates toward zero; thus -(///■)=-///=//-/ The mod operator yields the remainder of 
dividing one number by another (mod is not applicable to real operands), mod is defined by the 
relation (///)*y-f (/ mod j) = /, and the sign of the result of mod is always the sign of the dividend. 
(This is the reason that line 11 of Example 1 takes the absolute value of the computed gcd\ if 
m=-12 and a? =8 initially, the gcd would be —4 if its absolute value were not taken.) 

The built-in function min computes the minimum value in a list of expressions; similarly, the max 
function, the maximum value. The built-in function abs computes the absolute value of its 
argument. The syntax for calls on the built-in functions is 

BuiltinCall ::= MiN[ExpressionList ] | 

MAX[ExpressionList ] | 
ABS [Expression] | 

... - other built-in functions later 

ExpressionList :: = Expression | ExpressionList, Expression 

For the arithmetic operators and built-in functions, the order in which the operands are evaluated is 
undefined, but the syntax implies a precedence ordering that controls the association of operators 
with their operands. In that ordering, unary negation precedes the multiplying operators, which in 
turn precede tlie adding operators. Sequences of operators of the same precedence associate from left 
to right (with the exception of the embedded assignment operator, section 2.5.4). Thus, an 
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expression such as a+b*-c docs nol specify the order of evaluation of a, b and c but does require 
that the operations be performed in the following order: negate c: then multiply the result by b\ 
finally, add that result to the value of a. 



Fxamples: 

/, /, k: integer; nu n: cardinal; 



Factors: 



Products: 



Sums: 



// 

15 

ii-^j+k) 

-15 

min[/; / k. -15] 

m*n 

//"-15 

n MOD 8 

m/n*lO 

-^*(/+1)/2mod3 

z+l 

n-n MOD 8 
m — m/n*n 



same as {m/n)*lO because of left-associativity 
same as (((-A:)*(z+l))/2) mod 3 



same as n-{n mod 8) because of precedence 
same as m mod n 



2JJ.L Domains of the numeric operators * 

In principle, each arithmetic operator designates the corresponding mathematical function. 
Unfortunately, die hardware underlying any implementation of Mesa does not provide this function 
but only a set of related partial functions. For each operator, the compiler must choose as 
appropriately as possible from this set. The choice is made by considering the types of the operands. 

Example: 

With the usual assumptions, 177777B and -1 are represented by the same bit pattern. The 
value of 177777B > is true, but that of -1 > is false. 

Mesa provides the operators -h, -,*./, min, max and abs for all the numeric types. The operation 
mod is defined for all numeric types except real; the operation of unary negation, for all but 
cardinal and long cardinal. For each of these operators, the type of the result is the same as the 
type of the operands. In addidon, the result of the operation is considered to have signed 
representauon if all tlie operands have signed representation, and to have unsigned representation if 
all the operands have unsigned representation. Thus, adding two integer values yields an integer 
result, and dividing one cardinal by another yields a cardinal result. 



Some fine points: 

Division and modulus operations on short numeric values are substantially more efficient if their operands are 
unsigned. 

Addition, subtraction, and comparison of long numeric values are fast; multiplication and division are done by 
software and are relatively slow. 

Operations upon REAL values are implemented as calls on user-supplied procedures. These procedures must be 
assignable to variables declared as follows (chapter 5): 

FADD, FSUB. FMUL FDIV: PROCEDURE [REAL, REAL] RETURNS [REAL]: 

FCOMP: PROCEDURE [REAL, REAL] RETURNS [INTEGER]: 

-- returns a value that is: if equal negative if the first is less, positive otherwise 

FLOAT: PROCEDURE [LONG INTEGER] RETURNS [REAL]: 

All other REAL arithmetic operations are fabricated from these primitives. 
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Although the mathematical integers (Z) and real numbers are closed under all these operations 
(except division by zero), the subranges defining the types integer, long integer, cardinal and 
LONG CARDINAL generally are not. When the result of an operation falls outside the range of its 
assumed type, a representational failure called overflow or underflow occurs. In the current version 
of Mesa, // is the programmer's responsibility to guard against overflow and underflow conditions. 

Tlie implications of Mesa's conventions for subtraction are wortli emphasizing. If both operands 
have valid signed representations, the result has a signed representation. If both have only unsigned 
representations, the result has an unsigned representation and is considered to overflow if the first 
operand is less than tlie second. 

Example: 

/; integer; m, n: cardinal; 

/ ^ m—n\ -' should be used only if it is known that m >= n 

i *- \F m>= n THEN m-n ELSE -(n-m)\ - a safer form (section 3.6) 

The arithmetic operations are defined for operands that all have the same type, but it is possible to 
mix numeric types (and thus representations) within an expression. In this case, operands are 
converted as necessary to the "smallest" type to which all die operands conform, the operation for 
that type is applied, and the result also has diat type. The rule for expressions involving type real 
is easy to state: 

If any operand has type real, the real operation is used. 

The rules governing combination of numeric operands with differing representations involve some 
additional concepts and are stated in section 3.6. Again, the programmer should try to avoid such 
combinations when possible. (Recall that literals in integer Pi cardinal have whatever 
representation is required by context) 

25.7.2 The operator LONG * 

The built-in fianction long converts any value with a short numeric type to a long numeric type. A 
value with an unsigned representation is converted to long cardinal; one with a signed 
representation, to long integer. The syntax is as follows: 

BulltinCall ::= ... | long [ Expression ] 

This operation is necessary when the standard conversion rules do not give the desired result. It 
can also be used to emphasize the conversion. 

Example: 

LONG[m*A2] -- "short" multiplication, overflow lost 

LONG[m]*LONG[A/] -- "long" multiplication 

Some fine points: 

Lengthening a single- precision expression is substantially more efficient if that expression has an unsigned 
representation. 

The Mesa implementation provides standard procedures (not part of the language) for performing certain 
multiplication and division operations in which the operands and results do not all have the same length. These 
procedures provide less expensive equivalents of, e.g., LONG[m]*LONG[n]. 
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2.5,1.3. CHARACTER operators * 

Limited character arithmetic is possible and is sometimes useful for manipulating the encodings 
of CHARACTER valucs. T\\c following arithmetic operations are defined for operands of type 
character: 

A character value plus or minus a short numeric value yields a character value. 

Subtracting two character values yields an integer value. 

No other aritlimetic operations on characters are allowed. Since the results of character arithmetic 
depend upon details of the character encoding, such arithmetic should be used with discretion. 

Examples: 



c: character; digit: integer; 
digit ♦■ c - '0; 
c <- 'A + (c- a) 



assumes c is lower case 



25.2. Relational operators 

The relational operators include = and #, <, <= (less than or equal), >= (greater 
and their negatives (e.g., not<, '-<,'-> = , etc.). These operators always yield 
depending on the truth or non-truth of the relation expressed. The operators = 
most types; the others, to any or^ier^^ type (Le., to any type whose values are 
ordered). Ordered types include integer, long integer, cardinal, long 
BOOLEAN, CHARACTER (with the Ordering given in appendix C), enumerated types 
subranges of ordered types (section 3.1). 



than or equal), >, 

BOOLEAN results, 

and # apply to 

considered to be 

CARDINAL, REAL, 

(section 3.1), and 



The relational operators also include the composite operator in, which takes a numeric value as its 
left operand and an interval as its right operand. Its value is true if the left value lies in the 
interval and false otherwise. The syntax for relational operators is 



Relation 
RelationTail 



RelationalOperator 

Not 

SubRange 

SubRangeTC 

Interval 



Sum I Sum RelationTail 

RelationalOperator Sum | 
Not RelationalOperator Sum | 



in SubRange 
Not in SubRange 

= ~ I NOT 

= SubRangeTC I . . . 

= Interval | . . . 

= [Expression .. Expression ) 
( Expression .. Expression ) 
( Expression .. Expression ] 
[Expression .. Expression ] 



I 



- explained in chapter 3 
-explained in chapters 

I 
I 
I 



The extra syntax for SubRange and SubRangeTC is placed here to be consistent with later uses 
of the class Interval in chapter 3. The syntax for intervals follows mathematical notation: a square 
bracket indicates the inclusion of the respective end point in the interval, while a parenthesis 
indicates its exclusion. For example, the following intervals all designate the range from -1 to 5 
inclusive: 

[--1 .. 5] [-1 .. 6) (-2 ..6) (-2 .. 5] 
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In the above examples. -1 is the lower bound of each interval: the w/?/)^'/* bound is 5. The bounds of 
an interval are its end points, regardless of whether the interval is written as a closed, half-open or 
open one. The bounds are not required to be constants. An interval witli an upper bound less than 
its lower is said to be empty: no values lie in such an interval. For example, the following are all 
empty intervals: 

[-1 .. -2] [-1 .. -1) (~2 .. ->1) (-2 .. -2] 

Examples: 

Relations: // = 15 

m # n " or /?? *-= n 

i <= J 

(Kj) = (J<k) '- = with tw^o BOOLEAN operands 

/? IN [1 .. 5) -- /? >= 1 and n < 5 

/ NOT IN [-1 .. 5] -- only legal if / is signed (because ~1 is) 

A fine point: 

The relational operators, like the arithmetic operators, denote families of hardware operations when they have 
numeric operands. Again, there is one operation for each numeric type. If there is a unique "smallest" type to 
which all the operands conform, they are converted to that type as necessar>' and then the comparison is 
performed. There is no unambiguous choice of such a type for numeric operands with different representations: 
an attempt to compare two such values is an error. The precise rules appear in section 3.5. 

2.5.3. BOOLEAN operators 

The operators not (logical negation), and and OR apply only to boolean values. The syntax is 



Negation 

Conjunction 

Disjunction 



Relation | Not Relation 

Negation | Conjunction and Negation 

Conjunction | Disjunction or Conjunction 



NOT negates the logical value of a boolean expression, p and q has the value true if and only if 
both p and q are true, p or q is true if at least one of p or q is true. 

When evaluating a Boolean expression, evaluation of primaries is guaranteed to take place from left 
to right. In the operation and or or, the second operand is evaluated only if the first operand's 
value does not determine the value of the expression. 

A fine point: 

"a- and }" is equivalent to the IfExpr "IF x THEN > ELSE FALSE": i.e., when .v is FALSE, .v is not 
evaluated. 

"x OR v" is equivalent to the IfExpr "IF x THEN TRUE ELSE >•": i.e., when x is TRUE, y is not evaluated. 

It is therefore safe to have expressions of the form "x AND v". where y is defined onlv when x is TRUE, e.g., 
"x#0 AND c/x > 2", or "p=NIL OR p.f=0'\ 



Examples: 



Negations: not /=15 -- same as not(/=15) 

^q - q must be of type boolean 

-(/? AND q) 

Conjunctions: / <= j and j < k 
p AND ^q 
i=5 AND j NOT IN [-1..1] 

Disjunctions: ni>n OR m=l5 
^p OR ^q 
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2.5.4. Assignment expressions 



ITie assignment operation can be embedded in other expression forms. When it is, the result of the 
operation has the type of the LeftSide and the value received by tlie LeftSide in the assignment. 
Tlie "♦-" operator has the lowest precedence of any operator. Its syntax is the same as tliat of the 
AssignmentStmt: 

AssignmentExpr ::= LeftSide ^ RightSide 

If this fonn is used to perfonn multiple assignments, it is important to note that *'^" is n'ghh 
associative. Thus, the assignment expression a^b'^b-^l first assigns the value of b+1 to b and then 
assigns 6's new value to a. 

Examples: 

Assignment Expressions: 
m^lS 

m^n^n+l - same as m^(/2^(n+l)) 

^'*"0'^0*+l) MOD /i)*2 - all these parentheses are necessary 

Rules governing assignments of numeric values when the types are not identical are summarized in 
section 2.4.6. 

Fine point: 

Because the order of evaluation of the primaries is not defined, expressons such as "(/^y) + (/^^)" have 
unpredictable values and should not he used. 

2.5S. Operator precedence 

The following table summarizes the precedences of the unary and binary operators introduced in this 
section. The order is from highest precedence (tightest binding of operands) to lowest; operators on 
the same line have the same precedence. 

- -- unary negation 

*, /, MOD 

-}-, - - subtraction 

= , #, <, < = , >, > = , IN 

-, NOT 

AND 

OR 



Parentheses can be used to explicitly control the association of operands with operators. 



2.6. Initializing variables in declarations 

A variable may be given an initial value in a declaration. For example, the Boolean variable 
delimited could be set initially false by using the declaration: 

^e//m/7^^: BOOLEAN ^ false; 
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Variables (of the same type) can be initialized collectively: 
fh nO: INTEGER ^ -7: 

lliis declares two separate integer variables // and nO and initializes each to -7. 

Any expression that could be used as the RIghtSide of an assignment can be used to initialize a 
variable: 

/: INTEGER ^ ABS[?i\: " this will set / to 7 

iSquaredWHTEOER^ i*i\ - /5^w^/t^ is initialized to 49 

j: INTEGER ^ iSquared- / + 1 : -j is initialized to 49 - 7 + 1 = 43 

All initializations shown so far have taken "assignment" (or "*-") form. There is another form, the 
"fixed" (or " = ") initialization. For example, 

octalRadix: integer = 8; 

This means that octalRadix is to have a fixed value. // is never valid as the LeftSide of an 
assignment. We call octalRadix a constant because its value can never change after it is initialized 
(recall that the number 8 is called a literal). Normally, the term "constant" will include the term 
"literal"; if the distinction is important, then "literal" will be used. 

Initial values for fixed initialization can be arbitrary expressions. Paraphrasing the earlier example: 

iO: INTEGER = fi<BS[- octalRadix]; iOSquared: integer = iO*iO; 
jO:\mEGER = iOSquared-iO+l: 

The initializing expression can use values that are not known at compile time. In this example, if 
octalRadix did not have fixed initialization, the values of /ft iOSquared, and jO would be computed 
and assigned at run-time. Variables are initialized in the order of appearance in a declaration, and 
later declarations can use variables initialized earlier, as shown by the example. 

2,6,1, Compile- time constants 

Wherever possible, the Mesa compiler evaluates expressions containing only constants. If a variable 
is initialized using the fixed form and the expression can be evaluated at compile time, then that 
variable has a know^n value. Since it can never appear as the LeftSide of an assignment operator, 
it too becomes a compile-time constant (the variables 70, iOSquared, and jO in the previous section 
are all compile-time constants). 

Example: 

beta: integer = 3; 
alpha: miEC^ER = beta-V, 

In this case, alpha is a compile-time constant (with the value 2), since the expression beta—l 
involves only compile-time constants. Compile-time constants need not occupy memory at run-time; 
the compiler can replace references to compile-time constants, such as alpha and beta, by their 
known values. 

Some fine points: 

Knowledge of compile-time constant values can also be exploited when analyzing expressions, processing other 
declarations, or generating object code. 

One side effect of this propagation of constants is that the representation of a numeric constant is known at 
compile-time. For instance, alpha above is declared to be an INTEGER, but because its value is 2, it may also 
be used as a CARDINAL. However, declaring the type of alpha determines what kind of arithmetic (signed or 
unsigned) will be used to compute its value, whether at compile-time or run-time (section 2.5.1). 
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In certain contexts, an expression is required lo yield a compile-time constant value. A (sub)expression denotes 
such a constant if all the operands are compilc-iime constants and the operation is not one of those listed below 
(current restrictions): 

Conversion of a numeric value lo type REAL. 

Anv arithmetic or relational operation with operands of tvpe LONG INTEGER. LONG CARDINAL or 
REAL. 

Application of any function (chapier 5) other than a built-in function. 

ITie @ operation (section 3.4). 

The SELECT operation (section 4.3.3). 

2.7. More general declarations 

Preceding sections have introduced all the syntactic components of a declaration. The general form 
is defined as follows: 

Declaration :: = IdList : TypeSpecification Initialization ; 

For the moment, TypeSpecification is defined as one of the built-in types; chapter 3 describes 
other forms of TypeSpecification. 

TypeSpecification :: = PredefinedType| . . . 

PredefinedType ::= integer | cardinal | 

BOOLEAN I CHARACTER | 

LONG INTEGER I LONG CARDINAL I REAL I 

STRING I -see chapter 6 

word] - see fine point below 

UNSPECIFIED - see fine point below 

An Initialization is formally defined as follows: 

Initialization :: = empty | 

♦- Expression | 
= Expression | 



-other forms are given later 



Fine points: 



The predefined type WORD is provided to describe values on which bit-by-bit logical operations are to be 
performed. Currently, it is a synonym for CARDINAL. 

The predefined type UNSPECIFIED is a device for bypassing most type checking. An UNSPECIFIED value is a 
single machine word, and it matches the tvpe of anv object that occupies at most a sinele machine word, 
including INTEGER. CARDINAL, CHARACTER, BOOLEAN, UNSPECIFIED, STRING, and any user-defined 
type (chapter 3) that fits in a single machine word. 

For numeric operations, its representation is similarly fluid. If a CARDINAL and an UNSPECIFIED value are 
the operands of some arithmetic operation, then the UNSPECIFIED value is considered to be unsigned. If an 
UNSPECIFIED is combined with a signed value, it is treated as if it were signed too. If an UNSPECIFIED is 
combined with an UNSPECIFIED, they are both treated as signed. 

Less type checking is sacrificed by using LOOPHOLE (section 3.5.1) than by declaring variables with type 
UNSPECIFIED. 



20 



CHAPTER 3. 



COMMON CONSTRUCTED DATA TYPES 



Mesa encourages the programmer to augment the collection of predefined types by constructing new 
types. Types can be defined to describe objects that are structured collections of related values (e.g., 
a vector of Booleans, a table, or a complex number consisting of real and imaginary components). 
Mesa's type system has other, perhaps less obvious applications. These include expressing some" of 
the programmer's knowledge about a class of variables (e.g., that all take on values restricted to some 
known interval), separating variables with different semantics into different classes so that they 
cannot be confiased (e.g., to avoid "comparing apples and oranges"), and hiding implementation 
details of abstractions (e.g., to prevent the user of a table-lookup package from depending upon the 
internal organization of the table). 

Programmer-created types have the same status as Mesa's built-in types. They can be used to 
declare variables and to construct further new types. In addition, values of most constructed types 
can be operands of the fundamental operations (♦-,=,#). 

A new type identifier is declared using the following syntax: 

TypeOecIaration :: = idList : type = TypeSpecification ; 

Each idehtifler in the IdList is thereby declared to name the type denoted by the 
TypeSpecification. If this declaration form is compared to a normal declaration, i.e.. 

Declaration ::= IdList [TypeSpecification Initialization ; 

it can be seen that "type" fills the role of a TypeSpecification, and "= TypeSpecification" 
plays the role of Initialization. In fact, the newly declared identifier has type "type" and a value 
(which must be constant, hence the " = ") that is a TypeSpecification. 

Any predefined Mesa type (section 2.7) is a valid TypeSpecification; thus die following are valid 
type declarations: 

SignedNumber: type = integer; 
UnsignedN umber: type = cardinal; 
TruthValue: type = boolean; 
Char: type = character; 

These type identifiers are now valid type specifications and can be used to declare variables: 

u J: SignedNumber, 
n: UnsignedN umben 
b: Twth Value; 
c: Char, 

After this series of declarations, / and/ have type SignedNumber, which is equivalent to integer; n 
has type UnsignedN umber, which is equivalent to cardinal; etc. This is a trivial way of defining 
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new types. A more interesting way uses a type constructor as the TypeSpecificatlon and 
generates a truly new type, not just an additional name for an existing one. A TypeSpecification 
can be defined as 

TypeSpecification ::= PredefinedType | 

Typeldentifier | 
TypeConstructor 

(TYPE itself is m)t a TypeSpecification; it can be used only to declare types.) 

There is an important point worth emphasizing here. A TypeSpecification that is a 
PredefinedType or a Typeldentifier denotes an existing type and yields the same type every 
time it is used. A declaration such as the one of SignedNumber introduces a synonym for the name 
of an existing type. Synonyms can be more descriptive and thus improve readability, but they do 
not partition the set of values. The types SignedNumber and integer are fully equivalent, and 
values with these types can be used interchangably. On the other hand, a TypeConstructor 
constructs a new type. The rules for equivalence and conformance of constructed types depend 
upon the forms of their constructors and are discussed as the constructors are introduced. In some 
cases, each appearance of a constructor generates a unique type, i.e., writing the same sequence of 
symbols twice generates two distinct, incompatible types. For this reason, programmers usually 
should name such a type, using a TypeDeclaration, and thereafter use the type's identifier. Of 
course, introducing an identifier for a constructed type can make a program easier to read and 
modify in any case. 

The predefined types are described in chapter 2 (except for string in chapter 6 and process related 
types in Chapter 10). The simplest form of a Typeldentifier is given by 

Typeldentifier ::= identifier | -- which is a declared type 

- other forms given in chapters 6 and 7 

The rest of this chapter discusses the attributes and uses of some common constructed types: 
enumerations, subranges, arrays, records, and pointers. The syntax for TypeConstructor is 

TypeConstructor ::= EnumerationTC 

SubrangeTC 
ArrayTC 
RecordTC 
PointerTC 
LongTC 

ProcedureTC | 

ArrayDescriptorTC | 

RelativeTC | 

SignalTC | 

PortTC I 
ProcessTC 



- for enumerations 

- for subranges 

- for arrays 
-for records 

- for pointers 

- for long pointers, etc 

- see chapter 5 

- see chapter 6 

- see chapter 6 

- see chapter 8 

- see chapter 9 
-see chapter 10 



(The suffix "TC" is to be understood as an abbreviation for "TypeConstructor".) 

Enumerations define a set of values by giving a list of identifiers. These identifiers can be viewed as 
members of an ordered set. 

Subranges define types with values drawn from those of a larger, encompassing type but restricted to 
lie in a specified interval. The subrange takes on the characteristics of the enclosing type; for 
example, a subrange of integer can be used to declare variables that behave as integers but are 
constrained to take values within some interval. 
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Arrays are sequences of components that are homogeneous with respect to type and are accessed by 
computed indices ("subscripting"). Records are sequences of components that have potentially 
different types and are accessed using fixed component names ("selection"). Records and arrays are 
Mesa's aggregate data types. 

Pointers are scalar values used to access data objects indirectly. A pointer value is represented by an 
address. Pointers can be used to build linked lists, tree structures, etc. Long pointers are pointers 
capable of spanning a larger address space than ordinary pointers. 

Chapter 3 concludes witli a discussion of type detenninatioru \hc process by which Mesa decides 
whether an expression has an acceptable type for a given operation. This is closely related to 
questions of the equivalence and conformance of types. 



3.1. The element types 

This section describes a class of types called element types. Their common properties are the 
following: 

(1) They are ordered types; values of an element type can be operands of all the relational 
operators (section 2.5.2). 

(2) They are sca/ar types; a value with an element type does not have any visible or directly 
accessible internal structure insofar as the language is concerned. 

(3) They can be used to declare subrange types (section 3.1.2). 

(4) They are the only types allowed as index types of arrays (section 3.2). 

The element types are integer, cardinal, character, boolean, the types generated by 
EnumerationTC, and the types generated by SubrangeTC. Because of (3) above, this definition 
is recursive; subranges of subranges are allowed. The definition of the class ElementType is 

ElementType ::= integer | cardinal | character | boolean | 
EnumerationTC I 
SubrangeTC 

A fine point: 

Note that LONG INTEGER and LONG CARDINAL, although ordered scalar types, are not element types. It is 
not possible to declare subranges of these types or to use long numeric values as array indices. 

3.1,1 Enumerated types 

Consider the following declarations and a typical assignment: 

channels tate: mjEGER: 
disconnected: integer = 0; 
busy: integer = 1: 
available: integer = 2; 

channelState ^ busy; 

Suppose channelState is a variable that is intended to range over a set of three "states" named 
disconnected, busy, and available, which are represented by values 0, 1, and 2. These values have no 
real significance; 5, 6, and 7 would serve equally well. Enumerated types are well suited to such an 
application (where the underlying values are unimportant). The above declarations could be 
replaced by a single declaration of a variable with an enumerated range: 
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channelStale: {disconnecled, busy\ available}: 

cbauuelState ^ busy: 

'ITic effect is the same as before; channelStale is a variable with \alues ranging over the same 
"states", and similar assignment statements can be used. 

llie enumeration has some advantages over the original declarations: 

It is more convenient; the programmer does not have to provide values for disconnected, 
bus)\ and available. 

It allows more type checking. In the integer case, one could assign any short numeric 
value to channelState. 

It helps documentation; an enumeration shows all of its possible values. 

An enumerated type is constmcted by specifying a list of identifiers between braces, "{...}". These 
identifiers are not variables, but constants of that enumeration called identifier constants. They 
represent nothing more than their own names. 

The type constructor EnumerationTC is defined as follows: 
EnumerationTC ::= {IdList} 

The IdList supplies all the identifier constants for the enumeration, and duplication of identifiers is 
illegal. Separately specified enumerations are distinct. Every appearance of an EnumerationTC 
generates a new type that is not equivalent to, and does not conform to, any other enumeration. 
Thus the declarations 

foreground: {red, orange, yellow, green, blue, violet}', 
background: {red, orange, yellow, green, blue, violet}', 

specify two rfz^^r^'/]/ enumerations. It is illegal to assign background to foreground, despite the fact 
that the same identifier list appears in each declaration. Occasionally, the inability to declare any 
further variables with the same type can be used to advantage by the programmer. Otherwise, the 
best way to avoid such problems is first to declare a type and then to declare variables using the 
identifier of that type; for example: 

Color: TYPE = {red, orange, yellow, green, blue, violet}', 
foreground. Color, 
background: Color, 

This allows the assignment of background io foreground as well as the declaration of further variables 
with the same type (perhaps initialized differently). 

The identifier constants in two different enumerated types have no association whatsoever and do 
not need to be distinct from one another. To identify unambiguously the enumeration from which a 
constant is taken, one can, and sometimes must, qualify the identifier constant by the name of the 
enumerated type. For example, given the additional declaration 

Fruit: TYPE = {orange, lemon}', 

Color[orange\ denoies a color and Fruit[orange] denotes a fruit More generally, the syntax used for 
this form of qualification is 

Primary ::= .. .|Typeldentifier [ identifier ] 

(This adds a new case to the syntactic definition of Primary, which already allows an identifier 
constant) 
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Often qualification is not necessary; for instance, tlie following is permitted: 

hue'. Color: 

hue ^ orange: - the type of Awe implies Co/ar[om/?g^] 

In the following situations, an identifier constant need not be qualified, because the intended 
enumerated type is established by the context: 

as the RightSide of an assignment 

as an initializing Expression 

as a component in an array or record constaictor (sections 3.2.2 and 3.3.4) 

as an argument of a procedure (chapter 5) 

as an array index (section 3.2) 

as the right operand of a Relation, including that part of a Relation used to label an arm 
in a discrimination (section 4.3) 

as the bounds in a SubrangeTC (section 3.1.2) 

The values of an enumeration are ordered. The ordering is given by the order of appearance in the 
Id Li St used to construct the enumerated type. The leftmost identifier has the smallest value, and 
values increase from left to right. The following relations all have the value true: 

Color [red\ < Color[orange] 

CoIor[red\ < violet 

hue IN [red .. yellow] - assuming hue = orange 

There are two additional built-in ftmctions that are applicable to enumerations: 
FIRST [TypeSpeciflcation] yields the smallest value of the specified enumeration; e.g., 
FIRST [Colot]=red. Similarly, LASTfTypeSpecIf icatlon] produces the greatest value in an 
enumeration; e.g., last [Color]= violet. It is also possible to iterate over all values of an enumeration 
(section 4.5). ^ 

The predefined type boolean is really an enumerated type, and its definition is 
boolean: type = {false, true}; 

Thus, FALSE<TRUE, FIRST [BOOLEAN] = FALSE, and LAST [BOOLEAN] = TRUE. Note, however, that the 
bcxdlean constants true and false may always be used without qualification. 

3.1.2. Subrange types 

In many cases, die values of a variable are inherently range-limited. For instance, a value for day 
(of the month) lies in the range [1..31]. In other cases, the range is limited by design. For instance, 
a value for year might be limited to the range [1900.. 1999]. Mesa permits the user to declare such 
variables in the following way: 

rfa;'; CARDINAL [1 ..31]; 
j^e^r; CARDINAL [1900 .. 1999]; 

Since these intervals cover a subrange of cardinal, the variables day and year are called subrange 
variables. It is useful to think of day and year as having type cardinal with the additional 
constraint that values are restricted to the specified intervals. 
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Subrange types have a number of advantages and uses. Subrange declarations unambiguously 
document tlie range of values intended for a variable and thus aid software maintenance. I'he 
compiler is able to optimize storage allocation when dealing with range-restricted variables (for 
example, in arranging the fields of a record, section 3.3) and can take advantage of subrange 
declarations to generate more efficient object code. 

Ilie general fonn of a SubrangeTC is 

SubrangeTC :: = Typeldentifier Interval | 
Interval 

llie Typeldentifier must evaluate to an ElementType. Thus, one can declare types that are 
subranges of integer, cardinal, character, boolean, enumerated types, and other subrange types. 
For example, 

SymmetricRange: type = integer [~l..l]; 

Positivelnteger: type = cardinal [1..LAST [integer]]; 

UpperCaseLetter: type = character ['A..'Z]; 

DegenerateType: TYPE = BOOLEAN [true..true]; 

CooIColor: TYPE = ColoriyelIow.±/KSJ [Color]]: - excludes red orange, yellow 

AthroughM: TYPE = UpperCaseLetter[ k,'M]\ - subrange of a subrange 

The base type for a subrange is tiiat type of which it is a subrange and which is not itself a 
subrange; e.g., the base type for both UpperCaseLetter and AthroughM is character. 

The Expressions that define the end points of an interval must have types that conform to the 
type denoted by the Typeldentifier (or yield short numeric values if the identifier is omitted). 
Also, for the purpose of defining a subrange type, the end points must be compile-time constants, 

A fine point: 

It is permissable for the interval defining a subrange type to be empty. It is not legal to use a variable of such 
a type, but an empty subrange is sometimes useful for specifying the bounds of an array in a record declaration 
(section 3.2). 

A subrange type conforms to its base type, and a base type conforms to any of its subrange types. 
By extension, any two subrange types with the same base types are mutually conforming (even if 
they do not overlap in any w^ay). A more revealing point of view is that the value of a subrange 
variable has the base type as its type, and an assignment of a value to a subrange variable makes an 
associated assertion that the value is in the appropriate interval. A violation of such an assertion is 
called a range error. It is the programmer's responsibility to guard against range errors. As implied 
by this viewpoint, appropriate literals of the base type serve as literals of the subrange type, and any 
operations defined on the base type automatically extend to the subrange type (but usually without 
closure). 

Examples: 

/i; CARDINAL [0..10]; m; INTEGER [-5..5]; 

m ^ 0; n *■ 0; -- inherited literals 

/2 ^ AZ+ 1; --not valid if n = 10 

n ^ m\ -only valid if m IN [0..5] 

The preceding discussion implies that subrange restrictions can be ignored in answering many type- 
related questions; in this sense, subrange types are "weak." Two subrange types are equivalent if 
their base types are equivalent and if the corresponding bounds are equal. For these types, 
equivalence is much stronger than conformance. Equivalence becomes important when subrange 
types are used in the construction of other types. 
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FIRST and LAST are applicable to all subrange types and yield the corresponding bound. For 
example, first [CoolCoIof]=^ green and l/kst [AihroughM] = ^M. It is also possible to iterate over all 
values in a subrange (section 4.5). 

A line point: 

ITie operators FIRST and LAST are applicable to all element types, including INTEGER. CARDINAL and 
CHARACTER, as well as LONG INTEGER and LONG CARDINAL. When applied to the numeric types, they 
supply information about ihe range of values supported by a particular implementation. 

i. /. 2. /. Subranges of numeric types * 

The description above applies to subranges of both enumerated and numeric types. Numeric 
subranges introduce one further complication, which is the question of representation. Omission of 
the initial Typeldentifier in a SubrangeTC is permissable if and only if each bound in the 
Interval specifies a short numeric value. In that case, integer or cardinal is the base type, and 
the choice depends upon the representations of the bounds. 

A numeric subrange type has a signed representation if both bounds are elements of integer and at 
least one is not an element of integer H cardinal. Similarly, it has an unsigned representation if 
both bounds are elements of cardinal and at least one is not an element of integer PI cardinal. 
If both bounds are elements of integer H cardinal, values of that subrange type are considered to 
have both representations. Any other combination of bounds is illegal. 

Examples: 

5/.-[-10..10]; - signed representation 

s2: [100..33000]; -- unsigned representation (if 33000 > last [integer]) 

s3: [0..10); -- both representations 

With respect to the choice of signed or unsigned versions of arithmetic and relational operators, a 
quantity with both representations is treated flexibly. When combined v^ith an unsigned value, it is 
considered to be unsigned; the unsigned operation and result are chosen. When it is combined with 
a signed value, the operation and result are signed. The rules governing combinations of values with 
both representations depend upon the context in which the result is used; the default is to choose 
signed representation and integer operations. The precise rules are discussed in Section 3.6. 

Examples: 

/; integer; /i; cardinal; - plus the declarations above 

(signed) 5/ + 1 

si -^ sS 
si - / 

(unsigned) s2 + 1 

s2^ s3 



A fine point: 



The representation assumed for a literal also depends upon context In fact, any short numeric constant c is 
treated as if its type were [cA^ 



Mesa Language Manual 27 



3, /. 2 2. Range assertions " 



Assignment to a subrange \'ariable implies an assertion about tlie range of the expression being 
assigned. The programmer may make such an assertion explicitly, for any expression, by using a 
range assertion. If S is an identifier of a subrange type and e is an expression with a type T 
confonning to .S', tlie Primary S{e] has tlie same value as e and is additionally an assertion that e 
IN [first [.vn 7] .. LAST[5'n7]] is TRUE. In addition to user defined types, the basic types integer 
and CARDINAL may be used in range assertions. 

A program that violates one of its range assertions is in error In addition to providing 
documentation and (optional) mn-time checking, a subrange assertion affects the attributes attached 
to an expression. For example, an assertion of an integer range (or a signed subrange) forces the 
result to be treated as a value with signed representation. This is useful for controlling the choice of 
an operation when the intended one cannot correctly be inferred from the operands (section 3.6). 

Examples: 

/; integer; n: cardinal; S: type = [0..10]; 

CARDINAL [/] - / is asserted to be nonnegative 

51/?] -- asserts/? IN [0..10] 

3.2. Arrays 

Arrays are indexable collections of homogeneous components. In other words, the components of a 
given array all have the same type, and each corresponds to one index value in a range of indices 
associated with that array. The range of indices (which is actually a type called the index type) and 
the component type determine the array type. For example: 

earningsPerQuarten hRRfKi[\.A]o?\HiEQER\ 

declares a variable with a constructed array type having an index type of [1..4] and a component type 
of integer. Thus, earnings? erQuarter is an array of four integer elements: earningsPerQuarter[ll 
earningsPerQuarter[2l ... , earningsPerQuarter[4]. earningsPerQuarter by itself refers to the entire 
array variable. (Aggregate variables and components of aggregates are generally called "variables". 
If a distinction is needed, the term component is used and always means an item contained within an 
aggregate.) 

An index type must be an element type (other than integer or cardinal). A one-to-one 
correspondence exists between the components of an array and the values of the index type. This 
allows array elements to be accessed via "indexed references". An indexed reference selects and 
accesses the component corresponding to a particular index value. In its simplest form, it consists of 
the name of an array followed by a bracketed Expression with a type conforming to the array's 
index type. 

An index type can be specified using a type identifier: 

Quarter, type = [1..4]; 

profit, loss, earnings: array Quarter Of integer; 

thisQuarter: Quarter, 

earnings[thisQuarter] ^ profit [thisQuarter] - loss[thisQuarter\\ 

The arrays profit, loss, and earnings have Quarter as their index types, and thisQuarter is a subrange 
variable with type Quarter. 



28 Chapter 3: Common Constructed Data Types 

Index types may also be enumerations or subranges thereof. For example, 

CallType: TYPE = {longDislance, tieLine. toll local mPlanl}\ 
nearbyCalls: ARRAY CallTypeyolIJnPlani] Of CARomfKi: 

nearbyCaIh[h)caI\^ nearbyCalh{locaf\ + \\ 

Components may be of any desired type. In particular, the component type may itself be an array 
type. This allows an approximation of multidimensional arrays, which are otherwise absent in Mesa. 
For example, a two-dimensional data structure can be declared and used as follows: 

Mainx3by4: type = array [1..3] of array [1..4] of integer; 
mxy: Matrix3by4\ 

mxj [3] [4] ^ 0; - clear last component. 

In the assignment statement, mxy is an expression of array type (with index type [1..3] and 
component type array [1..4] of integer). mxv[3] is an indexed reference to the third component 
oi mxy. This in turn yields an expression of array type (with index type [1..4] and component type 
INTEGER). Thus, mx>'[3][4] is an indexed reference to the fourth component of that subarray. 
Because of left-associativity, mx>'[3][4] is the same as (mx>^ [3])[4]. 

An array constructor Qomisis of an optional type identifier followed by a list of values (syntactically, 
Expressions) enclosed in brackets. The list specifies values for components of an array in index 
order. The declaration below uses an array constructor to initialize an array that can be used as a 
translation table; i.e., octalChar[n] holds the character denoting octal digit n: 

ocmOar; ARRAY [0..7] OF CHARACTER = [0, 1, 7, '3, '4, '5, '6, 7]; 

Note that the number of values in the list (eight) matches the number of indices in the index type. 
This is required for array constructors, A special form using the replicator all is available for 
abbreviating array constructors in which all components have the same value. For example, the 
follow'ing two declarations are equivalent: 

dashes: array [0..7] of character ^ ['-, ^-, '-, '-, '-, '-, '-, '-]; 
dashes: array [0..7] OF character <- all [-]; 

Array variables may also be initialized using other array values. Consider the following example: 

JreshVectoK array [0..3) OF cardinal = all[0]; 
current Vector, array [0..3) OF cardinal ^ freshVector\ 

In this Qd&Q. currentVector \s initiahzed with freshVectofs value, i.e., all three of cuirentVectofs 
elements are initially set to zero. 

When the operands of any of the fundamental operations (♦-, = ,#) are arrays, the operation is 
applied on a component-by-component basis. The initialization of currentVector above uses 
assignment in this way. Similarly, the expression ''currentVector = freshVector' yields the result 
TRUE if and only if all three components of each array are equal (as they are in the above example). 
Because the declaration of freshVector uses fixed initialization, assignment either to the entire array 
or to one of its elements is illegal. 
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3.2.1. Declaration of arrays 

Arrays arc declared using the array type const mcton A r rayTC: 

ArrayTC :: = PacklngOption array IndexType OF ComponentType 

PackingOption ::= empty | - elements word aligned 

PACKED -- elements potentially packed within words 

IndexType :: = ElementType | 

Typeldentifier 

ComponentType :: = TypeSpecification 

Two array types are equivalent if both their index types and their component types are equivalent 
and if they are both packed or both unpacked (see below). An array type conforms to another if the 
tw^o types are equivalent. Thus it is possible to assign or compare array variables with separately 
constructed types if those types are structurally identical (see the assignment to current Vector above), 

A fine point: 

In additon, one array type freely conforms to another if the component type of the first freely conforms to that 
of the second, the index types are equivalent, and they are both packed or both unpacked (see section 3.5). 

Declarations of initialized array variables take the form 
IdList : ArrayTC Initialization 

The initializing expression must have an array type conforming to the one being declared. 

The previous section describes indexed references to array components. A formal definition follows: 

IndexedReference :: = Variable [Expression ]| 

(Expression )[ Expression ] 

Leftside ::=... I IndexedReference 

The Variable or the parenthesized Expression must be of some array type, and the bracketed 
Expression must conform to the index type for that array type. An IndexedReference is itself 
part of the definition of a Leftside (and therefore of a Variable, section 2.5). 

Some fine points: 

Unless an array is packed, each component is "aligned", i.e., begins on a word boundar>\ Currently, a byte is 
the smallest unit into which the elements are packed. Thus a packed array of CHARACTER wastes no space, 
but a packed array of BOOLEAN has considerable overhead. 

Since packed array elements are not necessarily word aligned, one cannot use the @ operator (section 3.4) to 
generate the address of an element. 

The length of an array is the number of its elements. For variables with an array type, the length is fixed and 
known at compile-time. (Dynamic arrays are possible in Mesa through the use of array descriptors, discussed in 
section 6.2.1.) 

The IndexType of an array may legally be an empty inter\al. In this case, no storage is allocated for the 
array. This is useful when the array appears as the last component of a MACHINE DEPENDENT RECORD 
(section 3.3) and the user will be obtaining storage for each record plus some number of array elements from a 
free storage manager. Note that [0..0) is not equivalent to [1..1), since the intervals specify different initial 
indices for the array. 

Three function-like operators are relevant to arrays (and more relevant to array descriptors): LENGTH, BASE, 
and DESCRIPTOR. These are discussed in section 6.2, but a brief summary is provided below. For this 
summar>-, arg denotes an expression with some array type. 

LENGTH [arg] - yields the number of array elements. 

BASE [arg] - yields a pointer value for locating the first array element. 

DESCRIPTOR [arg] -- yields arg's array descriptor value (consisting of base and length). 
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3.2,2. Array cofWructors 

In the preceding examples, array constructors are used only for initialization. Actually, constructors 
for arrays may be used in any RightSide context. An array constaictor is defined as follows: 

Primary :: = Constructor | ... 

Constructor ::= OptionalTypeld [ComponentList ] | all [ Component ] 

OptionalTypeld :: = Typeldentifier| empty 

ComponentList ::= PositionalComponentUst | 

-- other forms for record constructors 

PositionalComponentList ::= Component | 

PositionalComponentList , Component 

Component ::= empty | - elided component 

Expression | 

NULL 

The empty components in a constaictor are said to be elided, and null components are said to be 
voided. The values of both elided and voided components are undefined. In the first form of array 
constructor, the number of Expressions plus elided or voided components must match the length 
implied by the array type. The type of each Expression must conform to the array's component 
type. The expressions (and elided or voided components) are taken in order to form a sequence that 
is the constructed array value. 

Consider the following example: 

Tn>te TYPE = ARRAY [1..3] OF cardinal; 
triplet: Triple ^ Triple{ll AX U]: 

The declaration assigns 11 to triplet [I], 12 to triplet [2] and 13 to triplet [3]. 

When the array type is implied by context, the Typeldentifier may be omitted (see the discussion 
of record constructors, section 3.3.4). Thus the declaration above could be written as 

/r/p/^/: 7>/p/^ ^ [11, 12, 13]; 

Taken out of context, the constructor [11, 12, 13] is ambiguous; it could be assigned to any away of 
three numeric elements; for example: 

trio: ARRAY {Patty. Laverne, Maxine} OF LONG integer ^ [11, 12, 13]; 

The second form of constructor, using all, is only \alid when the array type is implied by context. 
The type of the Expression must conform to the array's component type. The value of the 
constructor is an array in which the specified value is replicated a number of times equal to the 
length of the array. The expression is evaluated just once. In the case of an array of arrays, the 
structure must be mirrored by nesting in the constructor, as shown by the following example: 

a//0^^e5: A/am.x56>'4 ♦- all[all[1]]; 

Some fine points: 

The value of an elided or voided component of an array constructor is not defined, but it will have some value. 
In particular, if the statement 

niplet ^ [1, , 3]: 

is executed after the previous assignment to triplet, the value of triplet [l] is undefined. 

Any array constructor in which all components are compile-time constants is a compile-time constant. Also, 
selection from an array that is a compile-time constant using a constant index yields a compile-time constant. 
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3.3. Records 



A record is an aggregate that allows a group of related data items of different types to be packaged 
together. In the definition of a record type, the type of each individual component must be 
supplied, as in the following example: 

MiJUmyTimc. type = RECORD [/i/r. [0..24), mins: [0..60)]: 
oldTime. newTime: MilitafyTime: 

Here, MilitaiyTime is a newly defined type, and oldTime and newTitne are record variables of that 
type. MilitaryTime is a two-component record type, where the first record component is named hrs 
and the second mins. Every MilitafyTime record contains both components, but different record 
objects have their own values for these components. 

A constructor of a record type contains a field list after the word record. Each element in the list 
specifies one (or more) components of tlie record. For MilitaryTime, the field list is [hrs\ [0..24), 
mins: [0..60)]. The component names, hrs and mins, are called field names. They are used to refer 
to components in any MilitaryTime record. For instance, the first component of oldTime may be 
selected using the qualified reference, ''oldTitne.hrs". 

One can construct an entire record value using a record constructor. For instance, the constructors 
below yield Military'Time values with hrs components that have the value 13 and mins components 
that have the value of the expression ">'+!"• 

Military^Time{lX y+1] 
MilitafyTime[hrs: 13, mins: y-^l] 

The second constructor is an example of a keyword constructor, since it specifies the name of the 
component (e.g., as ''hrs:'') with which a value is to be associated. 

A default value can be specified for any field in the definition of a record type. The default is used 
in constructing records of that type when no value is specified in the constructor. Defaults are 
useful for suppressing detail and ensuring initialization of fields. In the following example, the two 
constructors have the same value: 

Datum: type = record 

[ 

value: integer, 
nReads: cardinal ^ 0, 
nWrites: cardinal *- 1 

1; 

Datum{x] 

Datum[value: x, nReads: 0, nWrites: 1] 

The basic operations on (non- variant) record values include the fundamental operations ( = , #, ^), 
as well as qualification and extraction for accessing the record's components. 

33.1. Field lists 

There are two kinds of field lists, depending on whether the fields are "named" or "unnamed". 
(Field lists used to construct multi-component record types are almost always named). 

Syntax equations: 

FieldList :: = [ UnnamedFieldList ] | [ NannedFleldList ] 

UnnamedFieldList ::= TypeSpecification | 

TypeSpecificatlon , UnnamedFieldList 



32 Chapter 3: Common Constructed Data Types 

NamedFieldList ::= IdList : FieldDescription DefaultOption | 

NamedFieldList JdList : FieldDescription DefauttOption 

FieldDescription :: = TypeSpecification 

DefaultOption :: = ennpty | ^ DefaultSpecification - section 3.3.5 

Examples: 

[/: INTEGER, /?: BOOLEAN, r: character] -- a named field list 

[integer, BOOLEAN, character] - a similar, but unnamed field list 

\fl\ character, y?, /?: integer] -- components listed and declared together 

[/7; character, /2: integer, y3: integer] -- equivalent to the above 

Note that if one field is named, all must be named. Also, field names must be unique within a 
given field list. (The same identifiers may be used as field names in other field lists, however, or as 
names of declared variables.) 

Field descriptions in a named field list contain a type specification, indicating the type of the field. 
Any type may be specified, including an array type or (some other) record type. 

Some fine points: 

A field's type specification must not imply an infinite nesting of records. For instance, the following is illegal: 

A\ TYPE = record [6: B]: 
B: TYPE = RECORD [a: A]: 

Field lists occur in constructors of types other than records, such as PROCEDURES (chapter 5), SIGNALS 
(chapter 8), and in variant record specifications (chapter 6). 

Unnamed field lists are normally used when component names would be ignored if they were present This is 
common for functions that return single-component results. Unnamed field lists are sometimes used in 
specifying the input parameters for procedure variables that are to be set to one of several actual procedures. 
(However, an unnamed field list does not allow Calls using such a procedure variable to refer to the parameters 
by name.) 

3,3.2, Declaration of records 

The type constructor RecordTC is defined as follows: 

RecordTC :: = record FieldList | 

... -plus variant records (chapter 6) 

where FieldList is defined in the previous section. Separately declared record types are unique, 
even if they look the same. Every appearance of a record constructor creates a new type that is not 
equivalent to, and does not conform to, any other record type. In the example: 

RecTypel :t\pe = record [^,6: integer]; 
reel: RecTypel; 

RecType2: TYPE = record [a,6: integer]; 
rec2: RecType2\ 

rec3: record [^,6: integer]; 
rec4: record [a,b: integer]; 

the record variables reel, rec2, rec3, and rec4 all have different, non-conforming types. None of 
these can be assigned to any of the others (despite the similarity of their components). It is, of 
course, legal to assign to a component any value with a conforming type. For example: 

reel, a *- rec2,b ♦• rec3,a ♦- 5: 
rec4,a ^ recl,a\ rec4,b ♦■ recLb\ 
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Any single-component record type conforms to the type of its single component, but not vice versa. 
Tlie automatic conversion in this case requires no computation. 

Example: 

Bundle: type = record [v^/wc* integer]; 
recVar: Bundle', 
intVar: integer; 

intVar •*- recVan - means intVar ♦- recVar.value 

intVar '^ recVar+\: -- operand conversion 

recVar *- BundIe[intVaj]: - a constructor 
recVanvalue ^ intVaK 

This conversion simplifies dealing v^ith functions that return single-component records (chapter 5). 
It also provides a way of partitioning a set of variables that can be checked by the type system. In 
the example above, a direct assignment of intVar to recVar is invalid. Furthermore, no other single- 
component record type, such as 

Prime: type = record [v^/w^; integer]; 

can be confused with 5w«^/e; assignment of a Bundle value to a Prime, or di Prime to a Bundle, is 
illegal. Either a 5wn^/e or a Pr/me can, however, appear as a numeric operand. Defining Bundle 
and Prime as synonyms for integer would not provide this additional checking. 

Because of the uniqueness of constructed record types, record variables are typically declared in two 
steps: first the record type, then the record variables. The general form is: 

identifier : TYPE =RecordTC; -- define record type. 

IdList: identifier Initialization ; -same identifier as just defined 

Record variables can also be declared directly: 
IdList : RecordTC Initialization ; 

This form is not very usefial because the (unnamable) record type is not available for purposes such 
as declaring other records of the same type or writing constructors. 

The Initialization shown in these general forms applies to the entire record variable, not to 
individual components. Any Initialization must have the proper record type. Initialization of 
record variables is shown in the next example. 

noon: MilitaryTime = [hrs\\X mins\Q]\ 

midnight: MilitaiyTime = [hrs'S), mins:Q]\ 

time: MilitaryTime ♦- midnight', -- start time at midnight. 

Some fine points: 

The Mesa compiler packs record componenis into machine words The components may be arranged in an 
order that differs from the left-to- right order of the fields in the type constructor. All records of the same type 
have the same component arrangement. 

Normally, the user is unconcerned with the actual arrangement of record components. When component 
arrangement is important, the user may specify "MACHINE DEPENDENT" records. An example is: 

Inten-uptWord: TYPE = MACHINE DEPENDENT RECORD 

[ 

device: DeviceNumber, 
channel: [0..7]. 
. stopCode: {finishedOk. enorStop. powerOff], 
command: ChannelCommand 
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In this case, the user takes full responsibility for component arrangement. Components are positioned exactly as 
given, from left to right in machine words. In general, "fill" components are needed to ensure that no field 
crosses a word boundar\' (unless it starts on one). Components (such as CharinelCofnmarid} may ihemselxcs be 
aggregates occupying more than one word 

It is also the user's responsibility to "fill out" the record to a full word if the record crosses a word boundar\. 
{InterwptWord might be correct for a 16-bit machine, but not for a machine having a larger word length). 

Except in MACHINE DEPENDENT records, components are packed for storage efficiency. Some fields may be 
aligned (to the beginning of a word boundan.) and some may not. Components occupying a full word or more 
are always aligned: arrays. INTEGERS and pointers, for example. Subrecords may or may not be aligned, 
depending on their size. Packed arrays are always aligned, even if there would have been space in the 
preceding word for a byte-sized element. 

The function-like operator SIZE is often used to find the number of machine words occupied by a record of 
some type. The general form is: SIZE[TypeSpecification]. The result is a CARDINAL value, the number of 
words required by an object with the type specified by the argument. SIZE may be used to find the number 
of words required for any type of object. 

3,33, Qualified references 

Qualification is used to refer unambiguously to a named component of some record. The general 
form (which extends the definition of a LeftSide) is 

QualifiedReference ::= Variable, identifier] 

( Expression ). identifier 

Leftside ::= . . . | QualifiedReference 

The field name is said to be "qualified by" the record value (die Variable or Expression) to the 
left of the dot. The operator associates from left-to-right in the case of multiple qualification. For 
example: 

Latitude: type = record [J^gs: [0..360), mms, sees: [0..60)]; 
Longitude: iyPE = nECORD[degs\{-%.S%mins, sees: [Q,,^^^^^^ 
Position: jyPE ^ record [latitude: Latitude, longitude: Longitude]', 
somePosition: Position', 

Some of die possible qualified references to components of somePosition are listed below: 

QualifiedReference Refers To 

somePosition,latitude 1st sub-record 

somePosition,longitude 2nd sub-record 

somePosition latitude.degs 1st component of 1st sub-record 

somePosition,longitude,secs 3rd component of 2nd sub-record 

The association order for qualification means that names must Occur in the proper sequence; e.g., 
somePosition,?72ins,lofigitude is incorrect. Also, a quaUfied reference must be complete, i.e., names 
may not be skipped (as in somePosition,secs, which would be ambiguous in any event). 

QuaUfied references and indexed references have the same precedence (the highest possible) and 
may be intermixed. For example: 

recordOfArrays: RECORD [a,b: array [0..100) OF cardinal]; 
arrayO/Records: ARRAY [1..5] OF RECORD [/7,/2,/i: cardimal]; 

arrayOJ]iecords[5],i3 ^ recordOfArrays.a[0]\ - ("last" gets "first") 

A fine point: 

Qualification briefly opens up a given "name scope". For instance, in the record qualification, recx, the 
qualified name, x, must name a field of rec and selects that field. Scope is treated more fully in chapter 7. 
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3.3.4, Record constructors 



A record constructor assembles a record Nalue from a set of component values. In the following 
example, a constmctor is used as a RightSide of an assignment. 

MontliNatue: type = {Jan Feb, Mm\ Apr, May. Jufi Jul Aug. Sep. Oct. Nov. Dec}: 

Date: type = record 

[ 

day: [1 .. 31], 

month: MonthName. 

Kar: [1900 .. 2000) 

1: 
birthDay: Date: 

dd: [1..31]: mm: MonthName: yy: [1900..2000); now: [1900..2000) ^ 1976: 
birthDay <- Date\l'S. Apr. a20H'-33]; 

This constructor yields a record value w^ith type Date, The record assigned to birthDay contains the 
foUov^ing component values: 

Component Value 

day 25 

month Apr 

year /iow-33 (which is 1943) 

A Constructor is a Primary and may not be used as the LeftSide of an assignment. 

Record constructors are of two kinds: keyword constructors and positional constructors. Within both 
kinds, the component value for a particular field may either be supplied or be omitted. If it is 
omitted, the value of the field is determined by the DefaultOption appearing in the declaration of 
the field (section 3.3.5). 

Syntax equations: 

Primary ::= ... | Constructor 

Constructor :: = OptionalTypeld [ComponentList ] 

OptionalTypeld :: = Typeldentifier | empty 

ComponentList :: = KeywordComponentList | 

PositionalComponentList 

KeywordComponentList :: = KeywordComponent | 

KeywordComponentList , KeywordComponent 

PositionalComponentList ::= Component] 

PositionalComponentList , Component 

KeywordComponent ::= Identifier : Component 

Component ::= empty | -■ elided component 

Expression | -- explicit component 
NULL -- voided component 

The initial Typeldentifier, if present, must name the type of the record being constructed. 

In keyword constructors, the correspondence between constructor components and record components 
is strictly "by name". Keyword names may not be repeated in a constmctor, but tlie order is 
irrelevant For example, the following keyword constructors are equivalent: 

Date[day: 25, month: Apr. year, now— 33] 
Date[month: Apr. day: 25, year, now—^i] 
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All of these keyword consimctors specify values for all tlie components. In the following example, 
tlie first keyword constructor elides tlie mouth component (the place for the component value is 
specified, but no value is given): die second voids the motuh component (by specifying null instead 
of a value): 

Date[day\ 25, month'. , yean now— 33] - month is elided 

Date[day: 25, month: hull, year: /7ovv~33] - month \s voided 

Ilie distinction between an elided and a voided a field arises in the treatment of defaults (section 
3.3,5). Since the declaration of Date specifies no default value for montk both of these examples 
constRict records with a second component having an undefined value. 

In a positional const wet or\ the correspondence between constmctor components and record 
components is strictly "by position". The first constmctor component corresponds to the first record 
component, the second value to the second component, etc. Positional constructors may be used for 
bodi records and arrays (section 3.2.2). It does not matter whether or not fields are named in the 
definition of the record type. The following three constructors are equivalent: 

Date[day: 25, month: .year: now-- 33] -- value of moAi//? is undefined 

Dat e[2S, , now- 33] - value of 2nd component is undefined (elided) 

Date[25. null, now- 33] -- value of 2nd component is undefined (voided) 

Positional constructors may elide or void components as shown above, but components not supplied 
^ at the end of the list must be elided by supplying a sufficient number of trailing commas. 

Keyword and positional notations may not be mixed in a single constructor. The order of evaluation 
of components is not specified for either kind of constructor. 

The initial Typeldentlfier in a constructor may be omitted when the constructor is used as: 

the RightSide of an assignment (unless the LeftSide is an extractor, section 3.3.5) 

an expression in an Initialization 

a component of an enclosing record or array constructor 

an argument of a procedure 

the right operand of a Relation. 

In other cases, an initial Typeldentifier must appear. It is never incorrect to supply the identifier, 
and sometimes doing so improves readability. 

A fine point: 

Any record constructor in which all components are compile-time constants is a compile-time constant. Also, a 
field selected from a record that is a compile-time constant is itself a compile-time constant 

3,3:5, Default field values 

The definition of a record type may specify a default value for each field. These default 
specifications are optional; if present, they are used in constructing records of that type when no 
values for the corresponding fields are specified in constructors. An elided field, as discussed in the 
preceding section, supplies no value. Specifying some default treatment of a field also allows 
complete omission of that field in a constructor. In a keyword constructor, a field is omitted by 
omitting the keyword entirely; in a positional constructor, trailing fields (only) can be omitted by 
omitting the final commas. The positional constructor "[ ]" is considered to omit, not elide, its first 
component (if any). 
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In the following example, all constructors ha\'c the same value. 
Inferval: type = record 

[ 

range: integer, 
origin: integer ^ 0, 
direction: {up, down} *- up 

]■• 

Inter\al[range: 10, origin: 0. direction: up] -- all fields specified 

Intefyal[range: 10, origin: , direction: ] - origin, direction elided 

Inteiyal[range: 10] - origin, direction omitted 

Interval\\Q] -- origin, direction omitted (positional form) 

The syntax for specifying defaults in a NamedFieldList follows: 

DefaultOption :: = empty | *■ DefaultSpecificatlon 

DefaultSpecification :: = empty | 

Expression! 

NULL I 

Expression | null 
Note: In the final line, the vertical bar denotes itself and is embedded within an alternative. 

Only named fields may have default values. In a DefaultSpecification, the Expression must 
have a type that conforms to the type of the corresponding field. 

Suppose that /? is a record type with a field v of type 7. The above syntax allows five forms for the 
DefaultOption in the declaration of v. No matter which form is used, a constructor of an R may 
explicitly specify a value for the field v. The various options control whether the existence of the 
field must be made evident in the constructor, whether an explicit value must be supplied and, if 
not, what action is taken. The options are interpreted as follows: 

(1) v: T 

In a constructor, the value of v can be left undefined, but that must be indicated explicitly, 
by eliding or voiding the field. This rule also applies to an unnamed field. 

(2) v: T - 

Every constructor must supply an explicit value (not null) for v. 

(3) v: T ^ e 

If a constructor elides or omits v, the value of the expression e is used; voiding the field is 
not permitted. 

(4) v: T ^ NULL 

As in (1) above, except that the constructor may omit v entirely. If the field is omitted, 
elided or voided, its value is undefined. 

(5) v: T *- e \ null 

As in (4) above, except that a constructor may explicitly void v. If the field is omitted or 
elided, the value of e is used; if it is voided, its value is undefined. 

If the first or second form is used, the field cannot be omitted from a constructor: these forms are 
useful w^hen such omission is likely to indicate a programming error. Omission is permitted by the 
other forms, which differ in the default action for an omitted or elided field. These forms are 
appropriate when a field has some common and meaningful default value (the third and fifth cases) 
or, alternatively, is relevant only in unusual circumstances (the fourth case). The last three forms are 
particularly suitable for extending the definition of a record type; constructors in existing programs 
need not be modified. 
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Fine poinls: 

'l"he second form of field declaralion guarantees thai the field v has a well-defined value in any record created 
by a constructor (but not otherwise). 

If the Expression fonn of a default specification is used, that expression is evaluated at the time of 
construction but in the context of the declaration of the record, i.e.. the expression is treated as a parameterless 
procedure invoked by evaluation of the constructor (see chapter 5). 

ITie default value of a field cannot be specified in terms of other fields in the same record. Default values for 
fields of record types defined in DEFINITIONS modules (section 7.3.2) must be compile-time constants. 

Examples: 

R: TYPE = RECORD . 

I 

v/: CARDINAL, 
v2: CARDINAL ^, 
vi: CARDINAL ^3, 
v4\ CARDINAL *• NULL, 
v5: CARDINAL *- 5 I NULL 

]: 

- the following are valid 

- R[vl: L v2: 2] -- means R[vl: 1, v2: 2, vi: 3, v4\ null, v5: 5] 

R[vl\ , v2: 2, v5: ] -- means i?[v/: , v2: 2, v5: 3, v4: null, v5: 5] 

R[vl\ 1, v2: 2, v5: null] -- means R[vl\ 1, v2: 2, v3\ 3, v4: null, v5: null] 

- the following are not valid 

R[] -- neither v/ nor v2 may be omitted 

R[xl: 1, v2: null, v3: null] -- neither v2 nor vi may be voided 

3.3,6, Extractors 

Extractors are used to "explode" record objects and assign their components to individual variables 
in a single statement For example, the extractor below assigns the components of birthDay (defined 
in the previous section) to the variables dd, mm, and yy\ in that order: 

[dd, mm, yy] ^ birthDay; 

This has the same effect as the following three separate assignments, except that birthDay is 
evaluated only once: 

dd <" birthDay.dayi mm ♦- birthDay. month', yy ^ birthDay. year. 

An extractor resembles a constructor in form, but there are some important differences: 
An extractor may only be used as a LeftSide, never as an Expression. 
The "components" of an extractor specify LeftSides, not Expressions. 
Extractors always begin with a left bracket, never with a Typeldentifier. 

The type of the record value assigned to an extractor must be known to the compiler. This means 
that the following (rather useless) statement is invalid because the constructor's type cannot be 
determined: 

[dd,mm,yy]^[15,Apr,\9A'i\, -invalid 

The statement should specify the type of the constructed value: 

{dd,mm.yy]^Date\lS, Apr,\9A'i\, -valid 
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Hxtractors, like constructors, may use keywords. This allows an extractor to be written without 
regard to the record's component order. For instance, the following statements are equivalent to the 
first one in this section: 

[day: dd, mouilr. mm. year: yy] <- birihDay: 
[monlh: mm. day: dd. year: yy] <- birihDay: 

Hxtractors may elide or omit any item, in which case the corresponding record component is not 
assigned. The extractors shown below are equivalent: 

[day: dd. monlh: , year: yy] ^ birihDay: - monlh elided 

[day: dd, year: yy] *- birihDay: -- monlh omitted 

[dd\ , yy] <- birihDay: - 2nd component elided 

A positional extractor may omit trailing components without supplying trailing commas. The year 
component of birihDay is omitted below. 

[dd, mm] *■ birihDay: 

An extraction operation (unlike an ordinary assignment) yields no value. This means ihat an 
exiracior may not be embedded wiihin an expression. For example, the first statement following is 
illegal: the second is a valid alternative: 

r ^ [x, y, z] <- s; - invalid 
[x,y, z]^ r<^ s; -valid 

Syntax equations: 

AssignmentStmt :: = . . . | Extractor ♦- RightSide 

Extractor ::= [ KeywordExtractList ] | 

[ PositionalExtractList ] 

KeywordExtractList ::= KeywordExtract | 

KeywordExtract , KeywordExtractList 

KeywordExtract ::= identifier : Extractltem 

PositionalExtractList ::= Extractltem | 

Extractltem , PositionalExtractList 

Extractltem ::= empty] -- component is ignored 

Leftside -- component is assigned to Leftside 

The identifiers in a KeywordExtractList must be field names for the record type. Note that 
an extraction list can be empty, in which case the effect is to discard a record value. Extractors 
cannot be nested. 



3.4. Pointers 

Pointers allow efficient indirect access to objects. A pointer may refer to only one specific type of 
item. For instance, the following pointer provides access only to objects of type integer: 

iniPir: pointer to integer; 

Another pointer might be specified to point only to boolean objects: 

booIPir: pointer to boolean; 

These are different types of pointers since they have different reference lypes, integer and boolean. 
Furthermore, since integer and boolean are incompatible types, these pointer types are also 
incompatible; i.e., assignment of booIPir to inlPir, or vice versa, is disallowed. 
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A pointer value is represented by the address of some data object. Tliis object is called the pointer's 
referent. The postfix operator t may be applied to a pointer value of any type to yield that value's 
referent. The process of "following" a pointer to its referent is called dereferencing. 

A dereferenced pointer designates a variable. When tlie pointer is declared as above, the variable 
can be used as a LeftSide or as a Primary. Thus intPtr^ and booIPtrf are variables of type 
INTEGER and BOOLEAN respectively, llie statement 

boolPin ^ iinrPm = 0); 

is executed by following iniPtr to obtain a integer value, testing that value, and assigning the result 
to the BOOLEAN variable referenced by booIPtr. 

Sometimes a pointer is created simply to identify an object or to allow indirect access to a value that 
is not to be modified. Mesa provides readonly pointers for such' applications. A value with' a 
readonly pointer type cannot be used to update its referent. For example, the declaration 

ROintPtr. pointer to readonly integer; 

declares a readonly pointer. ROintPtn is a Primary with type integer but not a valid LeftSide. 

Any type specification is permitted as the reference type of a pointer type. The pointers declared 
below reference a named record type. 

Person: type = RECORD 

[ 

age: [0..200], 

sex: {male, female}, 

party: {Democratic, Republican} 

]; 

candidatel, candidate!: Person', 
winner, loser: pointer to Person: 

Pointers to record objects may be used to quahfy field names. If record candidatel is the referent of 
winner, then qualifications such as 

winner.age winner, sex winner.party 

select the corresponding components of candidatel. However, if candidatel were the referent, these 
same qualifications would select components of candidatel. When applied to a pointer, the 
operation of selection implies dereferencing. For example, winner.age specifies dereferencing winner 
to obtain a record variable of type ?6T5oa2 and then performing normal field selection on that record. 
Thus winner.age is an abbreviation of winnen.age. 

It is common to define a record type containing components that are pointers referencing objects 
witii the same record type. For example, the type declared as follows: 

FamilyMember: type = RECORD 

[ 

someone: Person, 

mother, father: pointer to FamilyMember 

1; 

might be used to create a tree of related persons in which the relations are expressed direcdy by 
pointer linkages. 
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ThQ fundamental operations ( = , #, <-) applied to pointer values deal- with the pointers themselves, 
noi witli their referents. In the examples: 

winner ♦- loser: 
winner^ *- loseri': 

the first sets winner to point to the same Person as loser: the second assigns the referent of loser to 
the referent of winner, and thus has a quite different effect. The fi.ill set of relational operators can 
be applied to pointers declared to be ordered: for example: 

orderedPtr: ORDERED POINTER TO Person: 

llie ordering is determined by the memory addresses that represent the pointers, not by the 
properties of the referents. Pointers not declared to be ordered can be only be compared using the 
operators = and #. 

There is one pointer literal, nil. It conforms to any unordered pointer type and denotes a pointer 
value that has no valid referent. For example: 

IF intPtr = NIL THEN boolPtr ^ nil; 
A pointer with value nil should not be dereferenced; the result is undefined. 

Pointer values are most commonly obtained from allocators that provide and manage storage for a 
class of objects. The unary prefix operator @ also generates pointers. When applied to a variable 
with type T, it yields a pointer to that variable with type pointer to T\ for example: 

winner *- ©candidate P, 

Pointer generation should be done with caution; it is possible for the resulting pointer to outlive the 
referenced object. A non-NiL pointer value widi no valid referent is said to be a dangling reference. 
The language does not prevent dereferencing such a pointer, but doing so produces an undefined 
result. // is the usefs responsibility to avoid dereferencing a dangling (or uninitialized) reference, 

3,4. L Constructing pointer types 

The type constructor for pointers is defined as follows: 

PointerTC :: = Ordered Base pointer to Readonly TypeSpecification | 

Ordered Base pointer Interval to Readonly TypeSpecification 

Ordered :: = empty | ordered 

Base :: = ennpty | base 

Readonly :: = empty | readonly 

The TypeSpecification in a PointerTC specifies the reference type of the pointer type. Two 
pointer types are equivalent if their reference types are equivalent and if their attributes Readonly 
and Ordered are specified identically. Thus equivalent pointer types can be constmcted in separate 
places, but they must have the same structure. One pointer type conforms to another if die two 
reference types are equivalent, if either the Readonly attributes are identical or the second is 
readonly and the first is not, and if either the Ordered attributes are identical or the first is 
ORDERED and the second is not. The Base attribute is ignored in determining conformance. 

In the following examples, the first type in each pair conforms to the second, but the second does 
not conform to the first: 

POINTER TO FamilyMember POINTER TO READONLY FamilyMember 

ORDERED POINTER TO Person POINTER TO Person 

ORDERED POINTER TO Date POINTER TO READONLY Date 
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Fine points: 

If one pointer type conforms to another, it confonns freely (section 3.5.3). Conformance of pointer types is 
extended by the following rule: one pointer type conforms freely to another if the second is READONLY, the 
reference type of the first conforms freely to the reference type of the second, and the Ordered attributes 
satisfy the restriction above. 

ThQ second form of PointerTC constructs a .subrange of a pointer type. Subranges of pointers have the usual 
propenies of subranges: e.g.. a pointer subrange type and its base type mutually conform (but not freely). The 
values of a subrange pointer are restricted to the given inter\al (and can potentially be stored in smaller fields). 
Subrange pointer t>pes are not recommended for general use. The\ arc intended primaril\ for constructing 
relative pointer types (section 6.3) which, unlike the subrange types, do not allow dereferencing without 
relocation. 

'Ihe attribute BASE specifies that values with that pointer type are to be used as base values for relocating 
relative pointers (section 6.3). Such values may also be used as ordinao" pointers. 

3.4.2. Pointer operations 

Tlie general form of an indirect reference is: 

IndirectReference ::= Variable t| 

(Expression )t 

Leftside :: = .. .| IndirectReference 

The postfix operator t performs explicit dereferencing of the pointer expression it follows. Its 
precedence is the same as indexing and qualification (the highest possible), and these operations can 
be intermixed. For example: 

^mi^;?.- ARRAY [0.. 10) OF POINTER TO F^m//>'A/6'mfter; 

group[i]t .mothert .someone -- {{((group[i])f).mother)^).someone 

If p is an arbitrary pointer expression, then pt can be read as ''ps referent" or "referent of p'\ 
Application of the t operator produces a variable that may be used as a Primary. Unless /? is a 
readonly pointer, pr (or any of its components) may also be used as a LeftSide. The definition of 
conformance implies that an ordinary pointer can be assigned to a readonly pointer, but not vice 
versa. Thus the referent of a readonly pointer is not necessarily immutable; i.e., its value might 
change during the lifetime of the readonly pointer. The Mesa language only prevents updates of the 
object through those pointers to it that are declared to be readonly. 

The syntax used for address generation is 

Primary ::=... | (g^ LeftSide 

The prefix operator @ produces the address of its operand. If jc is a variable of type 7, the value of 
(5x is a pointer to x, and its type is pointer to T. @jc can be read as "address of x". The 
operand for @ must be a valid LeftSide (it cannot be a constant or an arbitrary expression, for 
instance). The operator's precedence is lower than that of t; e.g., (S^jct is equivalent to @(xt) (or 
simply jc). 

Some fine points: 

There are variables that cannot be the referents of pointers and thus cannot be the operands of @. These 
include all "variables" with fixed initialization and components of such variables. In addition, a pointer \aiue is 
represented by a word address-.. Therefore, a referent must lie on a word boundar\'. an object having this 
propert\ is called aligned Variables are aligned except in the following cases: 

Elements of packed arrays are not aligned. 

Any component of a record that occupies less than a single word is not aligned (but arrays, even if packed, 
are always aligned). 



Mesa Language Manual 43 

Care must be taken so that a pointer to a declared variable does not exist longer than the variable to which it 
points. Consider the following example (which assumes familiarity with procedures, local variables and global 
variables): 

pointerL pointer!: POINTER TO INTEGER: -- two global variables 

Risky Proc\ PROCEDURE [/: INTEGER] = - / is a local variable 

BEGIN 
local: INTEGER: - and so is local 

pointerl *■ @/: - risky: / will disappear upon RETURN 

pointer! *■ @ local: - also risky 

-- the "risky" pointers are valid up to this point, but 
RETURN -- NOT after this statement is executed. 

END: 

After the RETURN statement is executed, local storage is released for other purposes: thus the pointers will 
reference unpredictable data when that storage is reused. One should use pointers with referents existing at least 
as long as the pointers. 

Pointers that are declared to be ordered may be used as operands of all the relational operators 
(section 2.5.1). For this purpose, they behave as unsigned numeric values. The definition of 
conformance implies that an ordered pointer can be assigned to an unordered pointer variable, but 
not vice versa, nil is not a valid ordered pointer constant, and the relation of its value to other 
pointer values is undefined. Also, the @ operator always produces an unordered pointer value. 

The following fine points cover pointer capabilities that should be used with caution (and avoided when possible). Some 
of these capabilities circumvent normal type-checking, and may result in unpredictable results if used. 

The type POINTER TO UNSPECIFIED (or simply POINTER) can access actual data of any type. Pointers of 
this type conform to any other pointer type, and vice-versa. 

Limited arithmetic can be performed on pointers, but programmers are encouraged to use BASE and RELATIVE 
pointers (chapter 6) if the purpose of the arithmetic is simple relocation. A short numeric value added to, or 
subtracted from, a pointer produces another pointer with the same type. Also, the difference of two pointer 
values with equivalent types is a CARDINAL. 

3J3, Long Pointers * 

Long pointers provide indirect access to objects having memory addresses that cannot be 
represented within a single machine word. Like long integers, they are essentially concessions to 
the limitations of hardware. Again, the long variant provides somewhat greater generality at 
somewhat greater cost. 

Long pointer types are constructed as follows: 

LongTC ::= long TypeSpecification 

The type constructor long can be applied to integer (chapter 2), any pointer type, or any array 
descriptor type' (chapter 6). No other type can be lengthened. 

Long pointers are typically created by lengthening (short) pointers as described below. In 
particular, nil is automatically lengthened to provide a null long pointer when required by context. 
The standard operations on pointers (dereferencing, assignment, testing equality, comparing ordered 
pointers) all extend to long pointers. 

Both automatic and explicit lengthening (using the operator long) are provided for pointer types, 
and the type pointer to 7 conforms to (but is not equivalent to) the type long pointer to T. 
Lengthening an expression with the first of these types produces a value with the second; i.e., the 
reference type and the Base, Ordered and Readonly attributes are unchanged. 
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Tlic operator @; applied to a variable of type T produces a pointer of type long pointer to Tif 
tlie access path to that \ariable itself involves a long pointer and of type pointer to T otherwise. 

Some fine points: 

Two conforming pointer lypes conform freely only if both are long pointers or both are not. 

NIL is lengthened in a standard way and has a universal representation. All other pointers are lengthened in a 
hardware dependent wa\. There is no normalization prior to operations on long pointers, and such pointers 
constructed other than by lengthening ma\ give anomolous results (e.g.. in comparisons). 

If either operand in a pointer addition or subtraction is long, all operands are lengthened and the result is long. 

Examples: 

R: TYPE = RECORD [f: F, ...]: 

p, q: POINTER TO R\ 

pp, qq: LONG POINTER TO /?; 

pT: POINTER TO T\ 

ppT: LONG POINTER TO 7"; 

- the following are valid. 

pp ^ qq; pp ^ nil; pp ^ p\ 

pp = qq, pp = NIL, pp = q: - long comparisons 

pT ^ @pjl ppT <- ®pp/. 

ppT *• ©/?./; -- pointer lengthened 

-- the following are not valid. 

pp = ppT\ - incompatible types 

p *- pp\ pT ^ @PP'fi " no automatic shortening 

3J,4, Automatic dereferencing 

Automatic dereferencing converts a pointer RightSide of type pointer to T into one of type T if 
that RightSide is followed by dot qualification (section 3.3.3), a bracketed array index, or a bracketed 
argument list (the last two are syntactically identical). For example, in the following two statements, 
the LeftSides are equivalent: 

mnner.party ^ Democratic, 
win nerf. party ^ Republican: 

Automatic multilevel dereferencing is possible. Given the following declarations, the three final 
assignment statements have the same effect: 

^c/wa/y4rm>'; ARRAY [0..20) OF integer; 

arrayPtr: POINTER TO ARRAY [0..20) OF integer ♦- @actual Array: 

arrayFinger: pointer to pointer to array [0..20) OF integer ^ (Q^arrayPtr\ 

actual Array[l] <- 3; 

arrayPtr[\] *- 3; - arrayPtn[l] ^3 

arrayFinger[\] *- y, - ^rm>^F/>zga-tt[l] <- 3 

A fine point: 

The pointer attribute BASE inhibits automatic dereferencing in the context of subscript or argument brackets. 
See section 6.3. 
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3.5. Type determination 



Every expression in a Mesa program has a type that can be deduced by static analysis of the 
program text. Such analysis is called type deiermination. The language imposes constraints on the 
type of each expression according to the context in which it is used. A program that does not 
violate any of these constraints is lype-correct: every valid Mesa program must be type-correct. 

In principle, every xariable and every expression has an inherent type derived from its stmcture. The 
inherent type of a variable is established by declaration: the forni of a literal implies its type, and 
each operator produces a result with a type that is a function of the types of the operands, hiherent 
types of some expression forms are listed below: 

Expression Inherent Type of Expression 

34 [34..34] 

NIL POINTER TO UNSPECIFIED 

X<y BOOLEAN 

X declared type of x 

array[i] type specified for the components of array 

@x POINTER TO type of X 

{x *- e) type of x 

The type rules in Mesa take two general forms, which are the following: 

The exact type required by the context is known, and a given type must conform to it. The 
required type is called the target type. 

The exact type required is not implied by context, but a relation that must be satisfied by a 
set of types is known. The process of satisfying that relation is called balancing. 

Situations in which the target type is known are simpler and more common; they will be discussed 
first. 

All assignment-like contexts establish a target type for the expression to be assigned. These contexts 
include not only assignment itself (where the target type is the type of the LeftSide) but also 
initialization, record construction (where the target type for each component expression is the 
declared type of the corresponding field), array construction, parameter list construction, and the 
like. 

Example: 

LType: type = record [c; CType]: 
I Van LType: 

IVar <- any Exp: " target type of any Exp is LType 

IVar ^ LType[c: someExp]: - target type of someExp is CType ... 
IVar.c *- someExp: -■ ... which is more obvious here 

The following rule applies to assignments: 

There is never any automatic dereferencing or type conversion of any kind for the LeftSide of 
an assignment, and the inherent type of the Lei\S\6e is the target type of the right side, (Of 
course, a LeftSide may contain subexpressions, such as array subscripts, that are themselves 
right sides and subject to conversion.) 

Certain other contexts imply a target type. For example, the target type for an array subscript is the 
index type of the array. Also, the target type of the expression following if, while, etc., is boolean. 
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If the inherent type of an expression is equivalent to the target type, the use of that expression is 
type-correct. If it is not equivalent, it may still be possible to obtain conformance by applying 
various type conversions, which are sometimes called coercions. In Mesa, there is at most one 
sequence of conversions that can be applied automatically to convert a value from one type to 
another. When implicit conversion from the inherent type to the target type is impossible, the 
program is in error; e.g., assigning a boolean value to an integer variable is never valid. 

Some fine points: 

When ihe larget type is well defined, certain expression forms may be abbreviated. Identifier constants need 
not be qualified, and explicit identification of the type of a constructor is optional. The abbreviated constructs 
have no inherent type when view-ed out of context, and the\ cannot be used in situations requiring implicit 
conversion. For example. 

R: TYPE = RECORD [7; INTEGER]: 

v: R ^ [i?[3]]: -- the second R cannot be omitted 

An Extractor never has an inherent type: the extraction is controlled by the inherent type of the RightSide, 
which therefore cannot be abbreviated or converted. For example, 

r RECORD [inner: RECORD L/7. J2: INTEGER]]: 

[L j] ^ r inner. - the field selection cannot be omitted 

3.5. L Type conversion 

There are four automatic type conversions that can be applied to establish type conformance. AH 
have been discussed in preceding sections. They are the following: 

(1) A value with a subrange type may be converted to a value with its base type, and vice versa 
(section 3.1.2). 

(2) A value with a single-component record type may be converted to a value with the type of 
that component (section 3.3.2). 

(3) A value with a short numeric, pointer or array descriptor type may be lengthened to a value 
with the corresponding long type (section 2.4.5). 

(4) A value with any numeric type may be converted to type real (section 2.4.5). 

The first of these is a somewhat special case; as mentioned in section 3.1.2, it is more accurate to 
view this as a pair of conversions that are applied unconditionally when evaluating, and assigning to, 
a subrange variable. 

Examples: 

r. RECORDlf: integer]; 

i: integer; 

//: LONG integer; 

7 *• n " i ♦- rf 

a ^ n - a *■ longI^/] 

Some fine points: 

A number of the conversions used to achieve conformance require computation and cannot be applied 
recursively to the constituents of constructed types. For example, INTEGER conforms to LONG INTEGER, but 
ARRAY JndexType OF INTEGER does not conform to ARRAY IndexType OF LONG INTEGER. Section 3.5.3 
discusses the concept of "free" conformance and the rules governing such cases. 

There is one other automatic conversion, dereferencing, that is applied onh in certain syntactic contexts (section 
3.4.4). It is never applied automatically to achieve type conformance in an assignment. 



Mesa Language Manual 47 

Sometimes il is necessao to subvert Mesa's type checking, particularly in programs that manipulate low-level 
representations of objects. A Primary with the form 

LOOPHOLE [ Expression , TypeSpecification ] 

has the same value as the Expression (viewed as a sequence of bits) and the type denoted by 
TypeSpecification. This "conversion" never requires any computation. The only restriction is that values 
with the inherent type of Expression must be represented in the same number of machine words as values of 
the type TypeSpecification. When the target type is well-defined, the TypeSpecification may be omitted. 
For example: 

b: BOOLEAN: n: CARDINAL: 

n <- LOOPHOLE [/>. CARDINAL]: - to discover the representation 

n ^ LOOPHOLE [/)]: ~ also acceptable 

Since LOOPHOLE bypasses most checking, its use should be limited as much as possible. 

3,5,2. Balancing * 

Many of Mesa s operators are generic; i.e., the operation performed depends upon the types of the 
operands. Examples are the fundamental operators = and #, which accept two operands with 
arbitrary (but compatible) types and produce a boolean result. In this case, neither operand has a 
defined target type. Instead, it is necessary to find some type to which the inherent type of each 
operand conforms; any automatic type conversions are applied to the operands as necessary to 
produce values of that type; and the operation is then performed. The common type is the "least 
upper bound'*, i.e., the one requiring the fewest conversions. 

Examples: 

R\ TYPE = RECORD L/: INTEGER]; 

RR\ TYPE = record[j9; long integer]: 

/: integer; 

//: LONG integer; 

r/, r2\ R\ 

rr, RR\ 

i = // -- long[/] = // 

rl = r2 - compared as records 

rl = / -- rLf = / 

rl = rr - LONG[r/.y] = rr,f 

Balancing is also applied to if expressions (section 4.2.1), select expressions (section 4.3.3), and the 
arithmetic and relational operators. 



Fine points: 



Many generic operators do not propagate the target type of the expression in which they appear: instead, the 
operands are balanced and combined to produce a result that is converted further if necessar>^ For example, 

// *• / 4- r. -- // <- LONG[/ + r.J] 

n <- LONG[/] + r: - // ^ LONG[/] + LONG [r.y] 

The current version of Mesa does not fully implement balancing when lengthening (or conversion to REAL) is 
required. The restrictions are: 

Operands of MIN and MAX and the alternatives of conditional expressions are lengthened to match the 
expression's target type, if any, and otherwise to match the type of the first operand. 

The endpoints of an inten^al in the right operand of IN are lengthened to match the type of the left 
operand, but the left operand is • never lengthened. 

The expressions selecting the arms of a selection (section 4.3) are lengthened to match the type of the 
selecting expression, but that expression is never lengthened. 
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3.5,3: Free confonnance * 

A number of the conversions used to achieve conformance require computation and cannot be 
applied recursively to establish the conformance of types constructed from pairwise conforming 
types. For example, integer conforms to real, but the conversion from integer to real 
transfonns the representation. Fhus a pointer to integer and pointer to real cannot validly 
have the same referent, and these types do not conform. 

llie relation of free conformance is less restrictive than strict type equivalence but is defined so that 
it can be computed recursively. Loosely speaking, one type freely conforms to another if a value of 
the first can always be used as a value of the second without any computation or run-time check of 
validity. The relations of equivalence, free conformance and conformance are not independent. 
Equivalence always implies free conformance; if two types are equivalent, each freely conforms to 
the other. Also, free conformance implies conformance; if one type freely conforms to another, the 
first also conforms to the second. 

Of the automatic conversions discussed in section 3.5.1, only a restricted form of the first (subrange 
conversion) can be applied to establish free conformance. The restriction (which arises from the 
representation of subrange values in Mesa) is the following: 

The subrange type T[L.j] conforms freely to T if / = first [7] and to T[Lk] if j < k. 

If automatic conversion (1) of section 3.5.1 must be applied in any other circumstance or if 
application of conversion (2), (3) or (4) of that section is required to establish the conformance of 
two types, they do not conform freely. 

Of the constructed types discussed in this chapter, array and pointer types also have rules for free 
conformance kss restrictive than equivalence. To summarize: 

One array type conforms freely to another if the index types are equivalent and the 
component type of the first freely conforms to the component type of the second (section 
3.2.1). 

One pointer type freely conforms to another whenever the first pointer type conforms to the 
second as defined in section 3.4.1. 

Free conformance is also important for procedure types (section 5.1) and variant records (section 
6.4). 

In the following pairs of types, the first conforms to the second (but does not freely conform): 

[0..100) [0..10) 

[5..10) [0..10) 

integer real 

pointer to P^rSO^ LONG POINTER TO PerSO/2 

In the following pairs, the first type ft-eely conforms to the second (but is not equivalent): 

POINTER TO [0..10) POINTER TO READONLY [0..100) 

POINTER TO READONLY [0..10) POINTER TO READONLY [0..100) 

ARRAY [0..1G) OF [0..10) ARRAY [0..10) OF CARDINAL 

Fine point: 

Note that POINTER TO [0.. 10) does not conform to POINTER TO [0..100) so that the following is illegal: 

p: POINTER TO [0..10): q: POINTER TO [0..100): 
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(/ ^ />: q't ^ 99: -- now pt = 99 

3.6. Determination of representation * 

ITiis section discusses the rules used by Mesa for choosing between signed and unsigned versions of 
tlie numeric operations. These rules assume that there are conversion functions (taking the fonn of 
range assertions, section 3.1.2.2) that convert values from cardinal to integer (from long cardinal 
to long integer) and vice versa. In botli directions, the "conversion" amounts to an assertion that 
tlie value is an element of integer PI cardinal (long integer D long cardinal). Such assertions 
must be verified by the programmer. 

For any arithmetic expression, the inherent representations of the operands and the target 
representation of the result are used to choose between the signed and unsigned versions of the 
arithmetic and relational operators. 

The target type determines the target representation. The preceding section describes the derivation 
of target types; in addition, a range assertion establishes the asserted type as the target type of its 
operand. If all valid values of the target type are nonnegative, the target representation is unsigned; 
otherwise, it is signed. The arithmetic operators propagate target representations unchanged to their 
operands, but the target representation of an operand of a relational operator is undefined. The 
target representation is also undefined in all other cases in which the target type is undefined. Thus 
each (sub)expression has at most one target representation. 

The inherent representation of a Primary is determined by its type (if a variable, function call, 
etc.), by its value (if a compile-time constant), or explicitly (if a range assertion). Possible inherent 
representations are signed and unsigned; in addition, a compile-time constant in integer H 
cardinal or a Primary with an inherent type that is a subrange of integer n cardinal is 
considered to have both inherent representations. Inherent representations of operands are 
propagated to results as described below. 

The operation denoted by a generic operator is chosen by considering first the inherent 
representations of its operands, next the target representation, and finally a preferred default. If the 
operation cannot be disambiguated in any of these ways, the expression is considered to be in error. 
TTie exact rules follow: 

If the operands have exactly one common inherent representation, the operation defined for 
that representation is selected (and the target representation is ignored). 

If the operands have no common inherent representation but the target representation is 
well-defined, the operation yielding that representation is chosen, and each operand is 
"converted" to that representation (in the weak sense discussed above). 

If the operands have both inherent representations in common, then 
if the target representation is well-defined it selects the operation; 
otherwise tlie signed operation is chosen. 

If the operands have no representation in common and the target representation is ill- 
defined, the expression is in error. 

In all cases, the inherent representation of the result is determined by the selected operation. 

The unary operators require special mention. Unary minus converts its argument to a signed 
representation if necessary and produces a signed result. 



50 Chapter 3: Common Constructed Data Types 

Example: 

If /?? and //have unsigned representation, both the following are legal and assign the same bit 
pattern to /, but the first overflows if /;/ < /?. 

/ <- ;??— ;?: / <- IF m >= ri THEN //?-/? ELSE —(a?— m)^ 

ABS is a null operation on an operand with an unsigned representation; it always yields a value with 
unsigned representation. Ihe target representation for the operand of long (or of an implied 
lengthening operation) is unsigned. 

Examples: 

/, /; integer; m, n: cardinal; 5, /; [0..77777B]; b: boolean 

-- the statements on each of the following lines are equivalent. 

i *- m+n: / ^ integer [/??+/?] -- unsigned addition 

/ ^ 7+ A?; / ^ n-i-j: i *- 7+ INTEGER [«] -- signed addition 

/^5-f/; / ^ INTEGER [5-] + INTEGER [/] - signed (overflow possible) 

n ^ 5-f r, n *- cardinal [5] 4- cardinal [/] - unsigned (overflow impossible) 

s*-5-/; 5 ^ CARDINAL [5] -CARDINAL [/] "Unsigned (overflow possible) 

6^5-/>0; 6 ♦-INTEGER [5] -INTEGER [/] >0 " signed (overflow impossible) 

/ ^ -m; / *■ - INTEGER [m] 

/ ♦- m-\-n*(J-\-n)\ i ^ INTEGER [;??] + (integer [/?]*(y+ integer [/z])) 
n >■ m^rf^{j-^n)\ n ^ m -¥ (/?*(CARDINAL [/] + «)) 

/ ^ W+/2*(5+A2); / ^ INTEGER [m + («*(CARDINAL [5] -h/2))] 

b ^ 5 IN [/-I .. 7+1]; b ^ INTEGER[5] in [|NTEGER[/-1] .. INTEGER[/"fl]] 
FOR S IN [/-I .. /+!]...; FOR 5 IN [CARDINAL [/- 1] .. CARDINAL[/+1]] ... 

The following statements are incorrect because of representational ambiguities. 
b ♦- / > n: b <- i+n IN [s .. 7] 
SELECT / FROM m => ...; / => ...; endcase 
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CHAPTER 4. 



ORDINARY STATEMENTS 



Statements are the units of action in Mesa; they control the flow of execution and the updating of 
variables. This chapter treats ordinaiy statements: those statements having wide applicability (such as 
assignment statements); later chapters cover the remaining statements. The following syntax lists the 
phrase names of all the statement forms covered in this chapter: 

Statement :: = AssignmentStmt | IfStmt | SelectStmt | NullStmt | 

Block I GotoStmt | LoopStmt | ExitStmt | ... 

Some statements have expression counterparts, with the same general purposes but slightly different 
constraints. For instance, assignment can be performed by an expression as well as a statement. 
The expression forms covered in this chapter are 

Expression :: = ... | AssignmentExpr | IfExpr | SelectExpr 

In Mesa, certain statement forms such as the if statement contain other statements. These statements 
in turn may contain still other statements, and so forth. Consequently, the term '^statement" should 
be understood to encompass the large and small alike. 

The dynamic successor of a statement embedded within anotiier depends upon the embedding form. 
For simplicity, the discussion assumes tliat most statements occur in the middle of a hypothetical 
series of statements. Execution paths within a statement are described for each form of control 
statement, and the successor is described in terms of a postulated ''Next- Statement, Next-Statement 
represents nothing more than completion of a given statement; another statement may or may not 
appear at that point in an actual program. 

Although execution of a statement can be aborted prior to its normal completion, the discussion of 
statement sequencing also assumes normal termination of each statement unless otherwise stated. 

In the examples, Stmt-O, Stmt-l, Stmt-l, etc. denote arbitrary statements, the details of which are 
irrelevant. 



4.1. Assignment statements 

Syntax: 

AssignnnentStmt :: = LeftSide ^ RightSide| 

Extractor ♦- RightSide 

The RightSide must be an expression with a type conforming to the type of die left-hand side. 
The left-hand side must be a valid recipient of data such as a declared variable or a component. For 
assignment statements, a left-hand side may also be an extractor (section 3.4.5). 
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Examples: 

/ <" .?; a <- b-{-c: 

birthDay.month *- Apr: birthTable\Tom].year ^ 1955; 

[mnh dd, yy] ^ birlhDay: - an extractor as the LeftSide 

4J.I. Assignment expressions 

Assignment operations may be carried out by expressions, as well as by assignment statements. The 
syntax for an assignment expression is 

AssignmentExpr ::= LeftSide ♦- RightSide 

Assignment expressions can be used for performing multiple assignments in a single statement, and 
for saving the value of an intermediate expression without having to write a separate statement: 

x2 *- xl ^ xO ^ v; - set xO, xL and x2 to the value in v 

a/T(3;'[/ ^ y-hl] *- x[/]; - j is changed while changing the array component 

Evaluation of the first statement proceeds as if it were written: 
x2 ^ {xl ^ (xO *■ v)) 

Note that x2 <- (...) is an assignment statement. The assignment expression, xO ^ v, yields the value 
assigned to xO, this becomes the RightSide value for the other assignment expression, and so on. 

There are two differences between an assignment expression and an assignment statement: 
The expression yields a value (in addition to performing assignment). 
The Leftside of an assignment expression cannot be an extractor. 

An AssignmentExpr is an Expression. Its type is the type of the LeftSide, and its value is the 
value actually assigned (possibly after type conversion) of the RightSide. The assignment operator 
has the lowest possible precedence. As a rule, an assignment expression embedded in another 
expression is enclosed in parentheses. 

A fine point: 

In an expression such as the following: 

a[k^k-¥l] + b[k]: 

the order of evaluation is undefined, and the embedded assignment may be executed either before or after 
e\ aluation of 6[/r]. Such use of embedded assignments should be avoided. 

4.2. IF statements 

An IF statement is a control statement that ftinctions as a two-way switch: 
IfStmt ::= IF Predicate ThenClauseEiseClause 

Predicate :: = Expression 

ThenCiause ::= then Statement 
ElseClause ::= empty | else Statement 

A simple if statement is shown below. 

IF V = THEN Writes trmg['DonQ:'] ELSE v <- v-1; 
Next' Statement 
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llic BOOLEAN expression (v == 0) is called the Predicate of the if statement, llie Predicate is 
evaluated first, and if true, the Statement in the ThenClause is executed (in this case a call on 
the procedure WriieSlnng). Upon its completion, execution continues at NexhSiatement. If the 
Predicate value is false, the Statement in tlie ElseClause, "v <- v-l", is executed: if there is 
no ElseClause control goes directly to Next-Statement. 

Other examples: 

IF (flag - on) AND / IN [m,.n] then z <- / -f iDelta ELSE / ^ m\ 

IF winner - = nil then 

BEGIN " this Statement is a block (section 4.4) 

totalAge ^ total Age -f mnner.age\ 

IF mnner. party = Democratic JHEt^ demoScore ^ demoScore+l 

ELSE gopScore ♦- gopScore-\- 1: 

end: -end of the ThenClause 

Note that a semicolon cannot follow a ThenClause when an ElseClause is present. 

If the Statement in a ThenClause is a second if statement, then the outer if may have an 
ElseClause only if the inner one does: i.e., an ElseClause "belongs" to the innermost possible if. 
For example: 

\F a >= THEN 

IF a>0THEN6^ 1 - a > means set b to I 

ELSE 6 ♦- 0: " a = means set b to 

- no action if a < 

It is recommended that "if...then if" combinations be avoided entirely unless the second if has an 
ElseClause. Often, a single if statement is sufficient. For example, let pi and p2 be arbitrary 
predicates. Then the following two statements have identical effect: 

IF pi AND p2 THEN Stmt: - recommended form (see section 2.5.3) 

if pi THEN IF p2 THEN Stmt: " longet form 

Fine point: 

If the Predicate is a compile-time constant the compiler does not produce object code for the text that would 
never be executed. This also holds for IF expressions. 

4,2 J, IF expressions 

The IF statement has a counterpart that is an expression. Its syntax is similar to that of an If Stmt: 
IfExpr :: = IF Predicate THEN Expression ELSE Expression 

There are two differences between an IfExpr and an IfStmt: 

The clauses of an if expression contain expressions, not statements: 
An IF expression must have an ELSE-clause. - 

Examples: 

slope *- IF y = THEN max ELSE x/y: - avoid division by zero. 

6 4- IF ^ >= THEN (IF a > THEN 1 ELSE 0) ELSE - 1: 
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FA'aluation of an if expression begins with exaluation of die Predicate (in tlie first example, y=0). 
If it is TRUE, the expression in the ThenClause (i.e., tnax) is evaluated, and its value becomes the 
value of the if expression. If the predicate is false, the EiseClause expression (i.e., x/>') is 
evaluated, and its value becomes the value of the if expression. The second example sets the value 
of b to -1, 0, or +1, depending on whether a is negative, zero, or positive, respectively. 

llie ThenClause and EiseClause expressions must conform to some common type (possibly 
after type conversion, as outlined in section 3.5.3)1 line type to which they conform is the if 
expression's inherent type. 

An if operator has the same precedence as an assignment operator, i.e., the lowest possible 
precedence, if expressions should be enclosed in parentheses when embedded in odier expressions. 



4.3. SELECT Statements 

The SELECT statement chooses for execution at most one statement from an ordered list " of 
statements. The choice is based upon the relation between a given expression and expressions 
associated with each selectable statement. Thus, this statement form permits multiway branching, 
not just the two way branching of an if statement 

A SELECT statement is shown below. The separator " = >" should be read as "chooses." The entire 
statement may be read as follows: "Select, using jc's value, from the comparisons preceding the 
substatements. First, (xs value) 'equal to zero' chooses Stmt'l. Second, 'in subrange m through n 
chooses Stmt-2. Third, less than m chooses Stmt-3. Otherwise, choose nothing." 

SELECT X FROM 

= => Stmt'l: 

IN [f7i,.n] => Stmt-2\ 
< m => Stmt'3\ 

ENDCASE 

The next four sections cover various forms of select, their precise syntax, and the expression 
counterpart of the select statement. The term "select", used by itself, includes both statement 
and expression forms. 

4J.1, Forms and options for select 

Syntax equations: 

SelectStmt ::= select Leftltem from -(the head) 

StmtChoiceSerles - (the arms) 

ENDCASE FinalStnitChoice -(the foot) 
1... 

Leftltem ::= Expression 

StmtChoiceSerles ::= TestUst => Statement ;| 

StmtChoiceSerles TestList => Statement ; 

FinalStmtGhoice ::= empty | 

= > Statement 

TestList ::= Test I TestList , Test 

Test ::= Expression | — no operator implies an equality test 

RelationTail 
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Hx ample: 
/: [0..5]: 

SELECT / FROM 

=>/ ^ /-hi: " /=0 

< 3 => BEGIN / ^ /: / *" /-I end: - /=1 or i=2 

= 5 => / ^ 0;* - / = 5 

endcase =>/■<- 2: - /=3 or i=4 (none of the above) 
NexhSuvemem 

In the execution of a select statement, the Leftltem is evaluated first: a sequence of comparisons 
then follows. Each ann of the select statement begins with one or more Tests. The Expression 
in each Test is evaluated and compared with the value of the Leftltem. The evaluation occurs in 
order, from left to right, and continues until a comparison succeeds or the TestList for that 
particular arm is exhausted. If a test succeeds, control passes immediately to die statement following 
the TestList in that arm (no flirther Tests are evaluated, even in that same list). If all Tests in a 
gi\en arm fail, the next arm in the series is tried. After a test succeeds and its associated statement 
is executed, control passes to Next-Statement. Thus at most one statement can be chosen in a given 
execution of a select statement. 

When combined with the Leftltem (perhaps witli an implied " = "), each Test must be a valid 
Relation. The type of the Expression in a Test must conform to the type of the Leftltem. If 
a Test uses "in Subrange", the base type of the subrange must conform to the type of the 
Leftltem. 

A single select arm may specify more than one test: 

select i*J-\-k FROM 

1, IN[7..10] => Stmt'l: " values: 1, 7, 8, 9, 10 

2, 5, >10 => Stmt'2\ - values: 2, 5, 11, 12, ... 
endcase; 

A final choice may be appended to a select to handle all remaining cases; it follows endcase. For 
example: 

Priority State: type = record[/0, //, /2, i3\ boolean]; 
oldState, newState: PriorityState\ 

SELECT true FROM - picks the first TRUE state: 



oJdStateAO 


=> 


Stmt'O: 


oldState.iL newState. iO 


= > 


Stmt'l: 


oIdState.i2, newState.il 


=> 


Stmt-2\ 


oldState. iS., newState. i2 


=> 


Stmt-3: 


ENDCASE 


=> 


Stmt'99: 



If this SELECT statement does not choose one of the first four statements, the final statement {Strnt- 
99) is executed. 



Fine points: 



If all SELECT arms (or those in some contiguous subseries) specift constant values in each Test, the compiler 
can produce code using a "jump table" for efficient selection. 

The other alternatives for SelectStmt apply to variant records and are discussed in Chapter 6. 
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4.3.2, The NULL statement 

llie NULL siatemenL which serves only as a placeholder, is often useful as the statement in an arm of 
a SELECT statement: 

NullStmt :: = null 

For example: 

SELECT currentChar FROM 

IN [0.;9] =>Stf}U'I: "Handle digits. 

in f A./Z] => Stmt' 2: "Handle capital letters. 

in [a./z] => Stmt'3: -Handle small letters. 

SP => null; "Ignore blanks. 

ENDCASE => Stmt'99: "Handle all other chars. 

4. 3. 3, SELECT expressions 

The SELECT statement has an expression counterpart. There are three differences between the 
expression and statement forms of select: 

(1) The choices in each arm must be expressions, not statements. 

(2) The arms are terminated by commas, not semicolons. 

(3) ENDCASE must be followed by " = >" and a final (expression) choice. 

Its syntax is defined by 

SelectExpr ::= select Left Item from --(the head) 

ExprChoiceList --(the arms) 

ENDCASE => Expression -- (the foot) 

ExprChoiceList ::= TestList => Expression , | 

ExprChoiceList TestList => Expression , 

Leftltem and TestList are defined in section 4.3.1. 

For example: 

/?/: integer; - Point on a line. 

fo, /?/: INTEGERS 0; " Bounds for a line segment, initially a null segment 

PointPosition: type = {left Margin, rightMargin, inside, outside, degenerate}; 
position: PointPosition', 

position 



^ SELECT pt FROM 




IN (/a./?/) 


= > inside, 




NOT IN [lo..hi] 


= > outside. 




<hi 


= > left Margin, 


" =/obut #/z/ 


>Io 


= > right Margin, 


" = hi but # lo 


ENDCASE 


= > degenerate: 


" = lo and = hi 



A SELECT expression is executed just as a select statement, except that the selected arm yields a 
value, which becomes the value of the select expression as a whole. The inherent type of a select 
expression is the one to which all the expressions in the arms conform (section 3.5.3). 

A SELECT operator has the same precedence as an assignment operator, i.e., the lowest possible 
precedence, select expressions should be enclosed in parentheses when embedded in other 
expressions. 
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4.4. Blocks 



A block is a way of packaging a scries of statements so that they can be used where only a single 
statement is permitted syntactically. In its simplest fonn a block is a pair of "brackets", begin and 
END, with a series of statements (of any form) between them. The general syntax is 

Block ::= begin 

OpenClause - optional; section 4.4.2 

EnableClause - optional; section 8.2.1 

DeclarationSeries -optional 

StatementSeries 

ExitsClause - optional; section 4.4.1 

end 

StatementSeries :: = empty | 

Statement I 

Statement ; StatementSeries 

DeclarationSeries :: = empty | DeclarationSeries Declaration 

A fine point: 

A semicolon terminates even' declaration and therefore is not mentioned as a separator here. 

In the following if statement, a block takes the place of the single Statement normally allowed in 
a ThenGlause; 

IF lo > hi THEN 

BEGIN - Exchange /o and hi. 
temp: integer <- lo\ 
lo <- hi: 
hi ^ temp: 

END 

A semicolon must separate each statement in the StatementSeries but is optional after the last 
statement. 

The optional DeclarationSeries in a block introduces new identifiers, such as temp above, with 
scope smaller than an entire procedure (or module) body. Scope is discussed further in sections 
4.4.2 and 5.5.1 and in chapter 7. 

Fine point: 

During the execution of a Mesa program, frames are allocated at the procedure and module level only (section 
5.2). Any storage required by variables declared in an internal Block (one used as a Statement) is allocated 
in the frame of the smallest enclosing procedure or module. When such internal blocks are disjoint, the areas 
of the frame used for their variables overlay one another. 

Ordinarily, when a block is executed, every statement in its StatementSeries is executed, and 
Next-Statement is the successor of the entire block. It is possible, however, to jump out of a block, 
as described in the next section on gotos. 

4.4,1, GOTO statements 

A more general form of a block allows a series of labeled statements to be written immediately 
preceding its end. One can jump to any one of these statements from within the block only, using a 
GOTO statement. There are two consequences of this way of constraining the goto: 

A GOTO may only jump forward in the program, never backward. 

A GOTO may only jump out of a block, never into one. 

The syntax for the ExitsClause of a block and for the goto statement is the following: 
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ExitsClause 

ExitSeries 

LabelList 

Label 

GotoStmt 



:: = empty I 

EXITS ExitSeries I 
EXITS ExitSeries ; 



- optional final semicolon 



:: = LabelList => Statement | 

ExitSeries ; LabelList => Statement 

::= Label I LabelList .Label 

:: = identifier 

:: = GOTO Label | GO to Label 



A simple example: 

\? inpuLsiatus # openlHEH 

BEGIN 

\F input fiIeHandIe=^ defauhlnputJHEH GOTO useDefauI^ 

-processing for non-default file 
IF input.fileNumber = ttyNumber THEN GOTO filelsDefault; 
w input Jength-Q THEH GOTO newFile\ 
... -- compute number ofpages in the file 

EXITS 

w5^/)e/^w//, y?/^/sZ)e/&w// =>-- multiple labels are allowed 

BEGIN input *- ttylnput\ pages ^ maxPagesEHD\ 
newFile => pages ^ 0\ 
end; -- end oftheThenClause and the if statement 

Next-Statement 

The Labels in this example are useDefaulu filelsDefault, and newFile (it is helpful to view the labels 
as the names of conditions or reasons for which the block is being left). If any one of the GOTOs is 
executed, control transfers immediately to the statement labeled with the identifier used in the GOTO. 
The normal successor of any one of the labeled statements is Next-Statement, which is also the 
normal successor of the last statement in the main body of the block (i.e., the one just before exits). 

Since one block can appear within the body of another, a goto can jump directly out of one (or 
more) blocks to the ExitsClause of an enclosing block. For example, 

-- outer block 



begin 

begin 

IF / = iMax THEN GO TO endOf Array: 

end; 

/ ^ /+1; 
exits 

endOf Array => / ♦- 0; 
end; 
Next' Statement 



inner block 

jump to end of outer compound 

end of inner 



end of outer 



If the GOTO statement is executed, control jumps to the exit labeled endOf Array, The chosen 
statement (/♦-O) is executed and control then goes to Next-Statement, The identifiers used as Labels 
are only known inside the block in which they appear, and it is possible to use the same identifier as 
a label in a number of blocks. If this is done in nested blocks, a goto naming that identifier will 
always go to the statement with that label in the smallest enclosing block. Generally, using the same 
label in nested blocks is a bad idea. 



Mesa Language Manual 59 

Since Mesa allows declarations in any block, it is possible to declare a. procedure (section 5.5) within 
die scope of the Labels of a block. Jumping out of a procedure into a surrounding block is 
disallowed. Such a result may be obtained, however, by use of the signal machinery (see chapter 
8). For example, the following is illegal: 

BEGIN 

p: PROCEDURE = 
BEGIN 

... GOlO pauicKxiK - illegal GOTO -- ... 

END; 

... />[]: ... 

EXITS 

panic Exit => ... 

END 

The desired result is achieved with the following program (see chapter 8 for a description of signals 
and catch phrases): 

BEGIN 

Panic: s\GMAL = code; 

/?: PROCEDURE = 
BEGIN 
. . . SIGNAL Panic: ... 

END; 

... p[ ! Panic => GOTO panicExit\\ . . . 

EXITS 

panicExit => ... 

END 

A statement in an ExitsClause may contain a goto, but the label in the goto can only refer to 
labels in surrounding blocks, not to labels in the same ExitsClause as the goto. For example, the 
following is legal: 

BEGIN -outer 

BEGIN "inner 

EXITS 

endOJFileReached => BEG\H ,., GOTO outOfData end; 
end; -end of inner 

EXITS 

outOfDafa => , , ,\ 
END -end of outer 

4,4,2, OPEN clauses 

An OPEN clause allows more convenient reference to the fields of a record. In the simplest form, it 
allows fieldname as an abbreviation for recordname,fieldname. If the name of the record is 
complicated (e.g., cafididateList[tabIeOJObjects[i]]X this can make programs much more readable. 
The programmer should be cautioned, however, that this is merely a syntactic shorthand; the code 
generated is actually recordnamcfieldname. Thus in the example above, if / or tableOfObjects is 
changing within the scope of the open, each reference to a field can potentially access a different 
element of c'andidateList, The syntax for open follows: 
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OpenClause :: = empty | open OpenList ; - note the tenninal semicolon 

OpenList ::= Openltem | OpenList , Openltem 

Openltem ::= AlternateName : Expression | 

Expression 

AlternateName :: = identifier 

llie scope of an open clause (the portion of the program over which the synonym can be used) is 
the body of a block or loop, including the optional exits clause (section 4.5). The following diagram 
summarizes die scope of the various parts of a Block. The scope of each phrase extends over 
others with greater indentation. 

BEGIN 

OpenClause 

EnableClause 

DeclarationSeries 
StatementSeries 
ExitsClause 

END 

An Openltem using an AlternateName allows a simple identifier to replace an expression as the 
designator of some record object. For example, the two blocks below are equivalent: 

PersonChain: type = RECORD [p: pointer to Person, next: pointer to PersonChain] 
candidateList: pointer to PersonChain: - Person is defined in section 3.5 

BEGIN OPEN c: candidateLislp; 

IF cparty = Republican AMD cage < 30 then youngRepublicans <- youngRepublicans+1; 

\fc.sex = Female THEH women ^ >vomeAz+l; 

END 
BEGIN 

\F candidateLisLp.party = Republican and candidateList.pMge < 30 then 

youngRepublicans ^ youngRepublicans-\-\\ 
\F candidateLisLp.sex = Female THEH women *- women-^-l; 

END 

The OPEN statement does not provide a general renaming capability; it merely allows more 
convenient access to the fields of a record. Each Expression in an OpenList must either have a 
record type or be a pointer to a record. When the AlternateName form is used, the alternate 
identifier always designates the opened record, even if the Expression is a pointer to that record. 

The form of OpenClause without an AlternateName allows access to the fields of a record 
object as though they were simple variables. For example, using this feature in the above example 
allow^s omission of the "c."s: 

BEGIN OPEN candidateLisLp: 

\f party = Republican and age < 30 then youngRepublicans *- youngRepublicans-^' 1; 

\? sex = Female IHEH women ^ women + 1\ 

END 

Note if the AlternateName form is used, qualification of record fields using the alternate name is 
mandator}'. 
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Besides record objects, one can open a module (chapter 7) to simplify access to the identifiers 
available from tlie module. 

If an OpenClause contains multiple Openltems, the opened expressions might refer to records 
having some selector names the same. In the example below, ;c is a selector name for two records, 
recVar and recVar.subRecord. An unqualified occurrence of x is taken to be the x component of the 
rightmost opened record {recVar.subRecord). To refer to an earlier opened record, explicit 
qualification is necessary (the AlternateName form should be used). 

/,/. integer: 

RecordType: type = RECORD 

[ 

a, k x: INTEGER, 

subRecord: RECORD [jc, y: integer] 

recVan RecordType; 

begin open rl: recVan recVar.subRecord: 
i *- rLa 4- rl.b * rLx\ j *- x—y: 
end; 

The above block is equivalent to: 

BEGIN 

/ ^ recVana + recVar.b * recVar.x\ j *■ recVarsubRecordx— recVar.subRecord.y\ 

end; 

Fine points: 

The range of text affected by an Open Item includes any further items in the OpenList. The OpenClause 
itself may use implied qualification or alternate names (from earlier Openltems). 

Opened expressions are evaluated at each use. whether used implicitly or explicitly under an alternate name. 
This is essential for dealing with relocating allocation schemes. To avoid confusion, however, it is recommended 
that ordinar> pointers be updated before entering the statement sequence headed by an OpenClause. In that 
way. names in the statement sequence will remain consistent, i.e., will apply to the same objects throughout. 

4.5, Loop statements 

In Mesa, a loop is a statement containing a series of statements that are to be executed repeatedly. 
All the ways of controlling how many times a loop should be repealed include the ability to repeat it 
zero times: i.e., to bypass it entirely. Example 1 in section 2.1 contains the following loop statement: 

UNTIL « = 
DO 

r^mVAQDn\ - r gets remainder of m//i 

m ♦- n\ n *- r, 

ENDLOOP 

"until «=0" is the loop control for this loop. A variety of loop controls are available in Mesa: they 
include control by a Boolean expression, as above, and control by iteration over a subrange, as in the 
following example: 

FOR / IN IO..iV) DO aOl > a[/] + fef/] ENDLOOP 

This will execute the assignment A^ times, with / taking the values 0, 1, ..., N-1 on successive 
iterations. If N = 0, the assignment is not executed at all 
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'Ilic fonnal syntax of loop statements is 

LoopStmt ::= LoopControl - optional; may be empty 

DO 

OpenCIause - optional (section 4.4.2) 

EnabieCiause -- optional (section 8.2.1) 

StatementSeries 

LoopExitsClause - optional; may be empty 

ENDLOOP 

ITie portion between do and endloop is the body of a loop. Subsequent sections discuss the forms 
of LoopControl, the LoopExitsClause and gotos in loops. 

The scopes of identifiers introduced in the various components of a loop are summarized by the 
following diagram (cf. Block, section 4.4.2): 

LoopControl 
do 
OpenCIause 

EnableClause 

StatementSeries 
LoopExitsClause 
endloop 

As in the case of a block, any exit labels are visible within the EnableClause, and any catch 
phrase in the EnableClause is not enabled within the LoopExitsClause. 

4,5, L Loop control 

The syntax for LoopControl is 

LoopControl :: = IterativeControl ConditionTest - either may be empty 
ConditionTest :: = empty | while Expression | until Expression 

If both the IterativeControl and the ConditionTest are missing from a loop, it will repeat 
indefinitely (unless terminated by an embedded goto or exit, section 4.5.2). 

If a LoopControl includes a ConditionTest, the Boolean expression in the test is (re)evaluated 
before each execution of the loop body, including the first If the ConditionTest succeeds: the 
body of the loop is executed; if- ii fails, the loop is finished {teiminates conditionally) and control 
continues at Next- Statement (or at a finished clause, see section 4.5.2). A while test succeeds if the 
value of the expression is true. In the following example, / has the values 1, 2, 3, ..., 9 in successive 
executions of the body of the loop, and the value 10 when Next- Statement is reached (assuming that 
there are no other assignments to /): 

/ ^ 1; -- this statement is not part of the loop 

WHILE /< 10 

DO.../*-/+l; ...endloop; 
Next' Statement 

An UNTIL test succeeds if the value of the expression is false: i.e., it is the opposite of while. The 
following loop is equivalent to the one above: 

/♦"l; "this statement is not part of the loop 

UNTIL/ >= 10 

DO ... / ♦- / + 1; ... endloop; 
Next' Statement 
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An IterativeControl provides a way of executing a loop (no more than) a precomputcd number of 
times. It may be followed by a ConditionTest. It optionally updates a specified 
Control Variable prior to each iteration so that, e.g., statements in the body have access to (a 
simple function oO the number of iterations. A loop that finishes by satisfying the implicit test 
associated with an Iteration or a Repetition is said to lenuinate normally. 

IterativeControl ::= empty | Repetition | Iteration | Assignation 

Repetition ::= through LoopRange 

Iteration ::= for ControlVariable Direction in LoopRange 

LoopRange ::= SubrangeTC |Typeldentitier | 

BOOLEAN I CHARACTER 

Direction ::= empty | decreasing 

Assignation ::= for ControlVariable ^ InitialExpr , NextExpr 

ControlVariable ::= identifier 

InitialExpr ::= Expression 

NextExpr ::= Expression 

In the Repetition form of IterativeControl, a LoopRange specifies how many times the loop 
body is to be executed. For example, 

through [1..100] DO . . . ENDLOOP 

executes the body 100 times. A loop range can have any element type (section 3.1) except integer 
or cardinal. The bounds of a subrange can be arbitrary expressions and do not have to be 
compile-time constants (as they do in a SubrangeTC used to define a type). 

A Repetition and a ConditionTest may be combined in a single loop control. For example, 
THROUGH [low.Mgh] while UnelsConnected do . . . endloop 

Normal termination occurs after high-Iow+l iterations; conditional termination can occur sooner if 
UnelsConnected is false prior to some iteration. Note that if low > high, the interval [Iow..high] is 
empty and the loop body is not executed. 

Iteration and Assignation, the two forms of IterativeControl that include a 
ControlVariable, begin with the keyword for. The control variable must be a variable declared 
separately in the program. Its type becomes the target type for the various expressions in the 
remainder of the IterativeControl. 

An Iteration steps through a subrange much as a Repetition, which is described above. In 
addition, it may specify a Direction: whether to begin at the lower bound of the range and step 
up (empty) or at the upper bound and step down (decreasing). In any case, the size of the step is 
always one; for (a subrange of) an enumerated type, this really means stepping from an element to 
its successor (if the direction is increasing) or to its predecessor (if the direction is decreasing). The 
control variable is assigned the current control value each time around the loop. 

When a loop terminates normally, the final value of the control variable is not defined. The only 
way to ensure that the control variable final value is well defined is to terminate the loop 
conditionally or forcibly (e.g., using exit or GOTO, section 4.5.2). 
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'ITie following examples shift the components of an array vec left or .right one position, leaving one 
element unchanged: 

FOR /IN [l.XENGTHfvfc]) 
DO 

v^c[/— 1] ^ V6^e[/]; -"Left-shift" v^'cs elements. 

ENDLOOP; 

FOR /DECREASING IN [LvLENGTHlvfc]) 
DO 

vec[i]*- vee[i-l]: -- "Right-shift" \w's elements. 

ENDLOOP; 

In the second case, / is initially set to the value length [v^c]-l and decremented by one for each 
subsequent iteration. During the last execution of die loop, / has the value 1. 

Bounds expressions in a Loop Range are evaluated exactly once, before the first execution of the 
loop body. Subsequent alteration of variables used in those expressions does not affect the number 
of iterations. When an Iteration is combined with a ConditionTest in a single loop control, the 
control variable is updated and tested before the ConditionTest is evaluated. 

In an Assignation, the value of the InitialExpr is assigned to the control variable prior to the 
first iteration. Before each subsequent iteration, the NextExpr is (re)evaluated and assigned to that 
variable. There is no implicit test associated with an Assignation as there is for an Iteration; 
thus, the user must either use a goto (section 4.5.2) to terminate the loop or include a 
ConditionTest in the LoopControl with the Assignation. As with an Iteration, the control 
variable is updated for each iteration before any ConditionTest is evaluated. This form is useful 
for scanning a list structure, as in the following example: 

NodeLink: type = pointer to Node: 
node,headOfList:NodeLink: 
Node: TYPE = RECORD 

I 

listValueiSomeType, 

next: NodeLink - either nil (end of list) or pointer to next element 

1; 

FOR node *- headOfList, node,next\JHT\L node=H\L 

DO . ..ENDLOOP; 

A fine point; 

The control variable can be altered within a loop, but this is not recommended. An iterative loop control 
updates the variable according to its current value. If the statement sequence assigns a new value to the control 
variable, the expected series of values may be disrupted (by omission or duplication). 

^.5.2 GOT05. LOOP5, EXIT5, a/I^/00/?5 

A loop may be forcibly terminated by a goto (or an exit, see below). The LoopExitsClause 
serves the same purpose as the ExitsClause in a Block; there are just three differences: 

(1) The LoopExitsClause is bracketed by repeat and endloop instead of exits and end; 

(2) The LoopExitsClause may contain a final statement labeled with the keyword finished; 
this statement is executed if the loop terminates normally or conditionally, but not if it is 
forcibly terminated. 

(3) There is a special case of the more general goto, called exit, which simply terminates a 
loop forcibly without giving control to any statement in the LoopExitsClause. 
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Tliere is another kind of goto statement, loop, which does not terminate the loop but skips the 
remainder of the loop body in the current iteration. 



Syntax equations: 




LoopExitsClause 


:: = empty | repeat LoopExits 


LoopExits 


::= ExitSeries | 
ExitSeries ; | 
FinishedExit | 
ExitSeries ; FinishedExit 


FinishedExit 


::= FINISHED => Statement 
FINISHED => statement ; 


LoopCloseStmt 


::= loop 


ExitStmt 


:: = EXIT 



The LOOP statement is used when there is nothing more to do in the iteration, and the programmer 
wishes to go on to the next repetition, if any. For example, 

stuff. ARRAY [0..100) OF PotentiallyInterestingData\ 

Interesting:, PROCEDURE [Potentially I nterestingData] RETURNS [boolean]; 

/: cardinal; 

FOR / IN [0..100) DO 

-- some processing for each value of / 

F -//2/eres/mg[5/Wj^/]] THEN LOOP; 

- process 5/w;^/] 

ENDLOOP; 

The example used in the previous section to illustrate ConditionTests can be rewritten using a 
GOTO and a LoopExitsClause as follows: 

DO 

IF i > = 10 THEN GOTO quit\ " first statement in the body 

... /^ /+1; ... 

REPEAT 

quit = > null; -- do nothing but exit the loop 

ENDLOOP ; 
Next-Statement 

Frequently, forcible loop termination requires no special processing in the LoopExitsClause. The 
EXIT statement simplifies tiiis case by not requiring a labeled statement in that clause; in fact, no 
LoopExitsClause need be present. The above example can be further rewritten to use exit, as 
follows: 

i^l; 

DO 

IF i>= 10 THEN exit; - first statement in the body 

... /♦■7-f 1; ... 

ENDLOOP; 

Next-Statement 
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An EXIT is less general than a goto. For instance, if one has a loop nested within another and 
wants to exit from both, exit cannot be used because it terminates only the inner loop. A goto can 
jump to the ExitsClause of any enclosing loop or block. The ExItsCiause of either a block or a 
loop is considered to be outside of the block or loop. 'ITius. an exit can appear in any 
ExitsClause (provided there is an outer loop), and it causes forcible termination of the smallest 
surrounding loop. 

The following example shows a typical loop tliat is tenninated only by execution of an exit 
statement. 

BufludexType: type = [\,.max]\ 
buf. ARRAY BuflndexType OF mJEGER: 
U x\ BufIndexType\ 

FOR / ^ X, (IF / = maxiHEH 1 ELSE /+ 1) " Starting at point x, 

DO 

-- do something and then 
IF buj[i] = THEN exit; -- quit on a "clear" entry, or 

ii{/[/] ^ 0; -- clear until one is found. 

ENDLOOP; 

The NextExpr, "if / = max then 1 else /+!", makes 6i// behave as a ring buffer. 

Sometimes one must detect normal (as opposed to forcible) termination of a loop, perhaps to take 
some 'Tmishing" action. A final labeled statement with the label finished (which may not appear as 
the identifier in a goto) provides this facility. For example, 

FOR /lN[0../2£'A2/ne5)DO 

IF a[i] = X THEN GO TO found: 

REPEAT 

found => old ^ true: 

FINISHED => BEGIN a[i ^ nEntries] *- x\ nEntries ^ nEntries + 1; old^ FALSE end; 
ENDLOOP ; 

The FINISHED exit is taken if and only if the loop terminates normally or conditionally (i.e., when the 
loop range is exhausted in the case above). Upon entry to a finished exit, the value of the 
ControlVarlable is undefined. Note that if an exit statement is executed, the finished statement 
is not executed. 
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CHAPTER 5. 



PROCEDURES 



Procedures provide one of the most important abstraction mechanisms available in Mesa. The 
definition of a procedure assigns a name to a flmction or action. The computation performed by a 
procedure is specified by a series of statements and can be expressed in terms of parameters of .the 
procedure. In addition, a procedure can produce one or more values, called its results. To invoke 
or call a procedure, the programmer simply names it and supplies arguments corresponding to the 
parameters. He need not be concerned with the internal workings of the procedure and can use a 
meaningful name to denote the function or action. 

The GCD computation in section 2.1 is of limited use as it stands because it depends upon (and 
changes) variables m, n and gc^ declared somewhere in its environment. It might usefully be 
packaged as a procedure with parameters /r? and n. Such a procedure is declared as follows: 

Cc^: PROCEDURE [m, n: integer] returns [cardinal] = 

BEGIN 

r: integer: 

UNTIL /? = 
DO 

r *- m MOD n; m *- n\ n ^ r, 
endloop: 

return [ABS[m]] 

end; 

The parameters of a procedure constitute the fields of a record, called the parameter record of the 
procedure. When calling a procedure, the arguments are evaluated and assembled into an argument 
record using a constructor (section 3.3.4.). "Applying" a procedure value to that argument record 
invokes the procedure. Consider the procedure call Gcd[x-{-\, y>\. This evaluates x4-l and y, 
constructs an argument record from these values, and then calls procedure Gcd, passing it the 
argument record. 

Within the procedure, the argument record is assigned to the parameter record, and fields of the 
parameter record are accessed as simple variables (i.e., that record is OPENed). Thus the effect of the 
call above is to assign the value of x+1 to m and the value of >^ to n before the statements within 
Gcd are executed. 

A procedure may return values to the point of its call. These results constitute a result record. 
There may be any number of results, and their types may differ. Within a procedure, a return 
statement assembles the results into a record and then returns control to the caller. The procedure 
Gcd returns a result record wath one component, of type cardinal. Thus the form Gc^[;c+1, >'] is 
an expression with a record type: because of the automatic conversion from a single-component 
record to the component (section 3.5.1), it can also be used in any context accepting a value of type 
cardinal. 
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ITie following assignment has an effect similar to that of the entire example in section 2.1: 

gcd >■ Gcd[ffK n] 

Note that arguments are always passed by value in Mesa. Tlie arguments m and n (for which 
declarations must exist at the point of call in this case) are completely distinct from the parameters m 
and //. and execution of Gcd does not change the values of the former. 

A procedure declaration with die fonn illustrated above is said to define an actual procedure. It 
introduces an identifier, supplies some procedure type for that identifier, and defines the computation 
to be performed by specifying a block called the procedure body. Such a declaration uses fixed form 
Initializatiori and closely parallels the declaration of an ordinary variable with = initialization, e.g., 

octal Radix: cardinal = 8; 

Other declaration forms may also be used, and this allows one to have procedure variables with 
values that can be updated to designate different actual procedures. In Mesa, procedures are full- 
fledged data objects. 

A procedure type is defined by specifying its parameter and result records. For example, the type of 
Gcd is 

PROCEDURE [m, n\ integer] RETURNS [CARDINAL] 

Procedure types constructed with different parameter and result records are different; thus the type 
system helps to guarantee that, even when procedure variables are used, a proper argument record is 
constructed for each procedure call (i.e., that the number and types of the arguments are correct) 
and that the result record is used correctiy in the text surrounding the procedure call. 

Since a procedure body is a block, it may contain declarations. These declare local variables for that 
procedure, variables that are created when the procedure is called, may be direcdy accessed only 
from within it, and are destroyed when the procedure returns. Within a procedure body, the named 
fields of the parameter and result records are also considered local variables; diey have the same 
lifetimes and can be referenced without qualification. The local variables of Gcd are m, n and r. 

Because this local storage is allocated and released dynamically, any Mesa procedure can be invoked 
recursively and used in a reentrant fashion. Thus the following alternative declaration of Gcd, which 
directly mirrors a recursive definition of the greatest common divisor, is valid: 

Gcd\ PROCEDURE [m, A?: integer] RETURNS [CARDINAL] = 
BEGIN 
RETURN [IF n = THEN ABS[m] ELSE Gcd[n, m MOD n]] 

end; 

A fine point: 

Although both versions of Gcd compute the same function, the recursive one is extravagant in its use of time 
and space (especially since an iterative version is so easy to derive). This demonstrates an advantage of 
procedural abstraction: the second definition of Gcd could be replaced by the first without effect on any caller 
of Gcd. Examples in section 5.4 demonstrate more appropriate uses of recursion. 

A procedure body may also access variables declared outside of the actual procedure. Such variables 
are nonlocal to the procedure; they exist longer than any single invocation of die procedure and 
must be defined in the enclosing program text. 

Mesa also has extensive facilities supporting the separate compilation of packages of procedures and 
variables; these packages are called modules (chapter 7). Some of these facilities allow^ one module 
to name and use the procedures in another, but the type-correct usage of argument and result 
records is still checked at compile-time. 
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If a procedure is called from many places, the "packaging" of code provided by die procedure body 
makes a program more compact. Procedure calls and returns do, however, introduce some runtime 
overhead. If a procedure is called from exactly one place, that overhead is unnecessary; if it is 
called from time-critical code or if the body of the procedure is very simple, the overhead can be 
unacceptable. Mesa provides inline procedures for such applications, llie call of an inline 
procedure is replaced by a modified copy of its body. This mechanism eliminates most of the 
overhead but retains many of the advantages of procedures, such as introducing staicture, improving 
readability and isolating detail. 

Die foregoing discussion is only an introduction to procedures. The rest of this chapter provides 
further detail. 



5.1. Procedure types 

Procedure types are constructed by the syntactic form ProcedureTC, w^hich is defined as follows: 
ProcedureTC :: = procedure ParameterList ReturnsClause 

ParameterList :: = empty | FieldList 
ReturnsClause ::= empty | returns ResultList 
ResultList ::=: FieldList 

The ParameterList and ResultList are Field Lists and define record types. If either is missing, 
the corresponding record type is "empty". A procedure type is fully determined by its parameter 
and result record types. 

Default specifications are permitted for fields of a ParameterList, but every field in a ResultList 
must have an empty DefaultOption, i.e., no default value can be specified for a result. 

Some fine points: 

Notice that constructors of procedure types require specification of the field hsts: it is not possible to use a 
separately defined record type to specify the complete parameter or result record. 

These records, unlike regular records, are not packed: ever\ component is aligned (begins on a word boundar\') 
to allow efficient passing of arguments and results. 

A few typical procedure types are shov^n below: 

PROCEDURE -- takes no arguments; returns no results 

PROCEDURE [x: INTEGER, yZag: BOOLEAN] - takes two arguments 

PROCEDURE RETURNS [/: INTEGER] " returns a single value 

PROCEDURE RETURNS [/: INTEGER, b: BOOLEAN] - returns two results 

PROCEDURE [x: integer] RETURNS [y: INTEGER] - takes and returns one value 

These are all distinct types; none conforms to any of the others. 

Values with procedure types are allowed in Mesa; one may have procedure variables, arrays of 
procedures, records with components that have procedure types, and procedures with procedure 
parameters or results. The fundamental operations =, # and ♦- may be applied to procedure values 
with conforming types. 

Constructors of procedure types appear most commonly in the declarations of actual procedures, but 
they may occur wherever a TypeSpecification is valid. Thus a ProcedureTC can appear in 
such constructs as: 

A variable declaration: 

EirorHandler. procedure [which: ErrorCode] <- DefauItHandlen 
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A type declaration: 

/;/5//^AW: TYPE = PROCEDURE [m: /j'5/] RETURN 

FirsU Rest, Last: LAstProc 
A field list (notice the parameters /^ssr/?^; and 5H^^/?): 

\Vo/7: PROCEDURE I 

firsU 7^5/: CARDINAL, 

7(?55r/?a/r. PROCEDURE [cardinal, cardinal] RETURNS [boolean], 

5n^: PROCEDURE [cardinal, cardinal] 

■'■■■..■■. ^ ■ 

An array declaration: 

/Op5: ARRAY O/^A^am^'S OF PROCEDURE [7, 71 RETURNS [7]; 

5././. Procedure values and compatibility * 

Equivalence and conformance of procedure types are defined in terms of relations between fields of 
their ParameterLists and ResultLists. If the number of parameters or results differs, one 
procedure type neither conforms to, nor is equivalent to, another. Otherwise, corresponding fields, 
matched according to position, are considered. Two procedure types are equivalent if, for each pair 
of fields, the names are identical (or both are unnamed), the types are equivalent, and both 
DefauitOptions are empty. One field is compatible with another if the names are identical or if 
either is unnamed, and if the types are equivalent. A procedure type conforms to another if all 
corresponding fields are compatible. Default specifications do not affect conformance. 

All the assignments in the following example are valid because the types of the procedures conform: 

Handle\iyPE-PO\m^RioPerson\ 

SignedNumber\iyPE-miEOER\ 

//z/: TYPE = integer; 

ProcA: PROCED\Jf(E[h: Handle, v: SignedNumber]\ 
ProcB: PROCEDURE[h: Handle, v: Int]: 

PmcC: procedure [pointer TO Per5G>AMNTEGER]; 

ProcA ^ ProcB: ProcA ^ ProcC: 
ProcC ^\F flag JHEH ProcA ELSE ProcB; 



Fine points: 



In the current version of Mesa, the name of the component of a single-element parameter or result record is 
ignored when comparing two procedure types for conformance. 

If one procedure type conforms to another, it also conforms freely (section 3.5.3). Free conformance of 
procedure types is actually defined by the following less restrictive rule: One field is compatible with another if 
the names are identical or either is unnamed, and if the type of the first freely conforms to the type of the 
second. One procedure type freely conforms to another if, for the ParameterList, each field of the second is 
compatible with the corresponding field of ihQ first and, for the ResultLlst. each field of \he Jirst is compatible 
with the corresponding field of the second. 

In the following example, recall that Handle conforms freely to ReadOnlyHandle but not vice versa: 

ReadOnlyHandle: TYPE = POINTER TO READONLY Person: 

ProcX: PROCEDURE [in: ReadOnlyHandle] RETURNS [out: Handle]: 

ProcY: PROCEDURE [in: ReadOnlyHandle] RETURNS [out: ReadOnlyHandle]: 

ProcZ: PROCEDURE [in: Handle] RETURNS [out: ReadOnlyHandle]: 

-- valid assignments 

ProcY ^ ProcX: ProcZ ^ ProcY: 

- invalid assignments 

ProcX ^ ProcY: ProcX ^ ProcZ: ProcY ^ ProcZ: 
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In detcnnining the confonnance of two procedure types, any default specifications are ignored, 
llius it is possible to assign a procedure value to a procedure variable with differently specified 
defaults. In a procedure call, the type of the variable appearing in the call, not die declaration of 
tlie actual procedure, determines the treatment of defaults. Tlius die initializing declarations in the 
following example are valid. Note that tlie declaration of Proc2 declares a procedure constant that is 
indistinguishable from Prod except for the default value of its argument. 

Which: TYPE = {procL proc2, proc3}\ 

Prod: PROCEDURE [p: Which ^ prod] = 

BEGIN 

end; 

Proc2: procedure [p: Which ^ proc2] = Prod: 

ProcS: procedure [p: Which] <- Prod; 

-some calls 

Prod[]\ -equivalent to P/"oc/[/?roc/] 

Proc2[]: -equivalent to Proc/[/?roc2] 

Proc3[proc3]: - note that ?roci[ ] is not legal 

5.2. Procedure calls 

The syntax for calling a procedure is 

CallStmt ::= Variable I Call 

Gall ::= Variable [ ComponentList ] | .. . 

where the Variable has some procedure type. Other forms of Can are discussed in chapter 8. These specify 
"catch phrases" for deahng with signals (or errors) that are generated because of the call. 

ParameterLists and ResultLlsts are FieldLists (section 3.4.1). In a call of a procedure, the 
arguments are packaged into a record. Therefore, a procedure call may use all the syntax for record 
constructors in passing arguments. Components (arguments) may be specified using either keyword 
or positional notation; arguments not explicitiy specified may be supplied by default. The following 
calls of Gcd are equivalent: 

Gcd[x-\-l, y] Gcd[m: x-hl, n: y] Gcd[n: y, m: x+1] 

If the ReturnsClause in a ProcedureTC is not empty, then its ResultLlst specifies the number 
and types of the results returned by a procedure of that type. It may be a named or an unnamed 
FieldList (section 5.3.1 on the return statement discusses how it is used). 

Procedures that return results must be called from within Expressions that use the results in some 
way. 'S>VLQh function references are valid Expressions. Procedures that do not return results are 
used in call statements. A procedure that does not return results is called by simply writing a 
CallStmt as a statement by itself For example, 

group: array [L.A^] of pointer to Person: 

Younger: procedure [//r5/, 5eco/7^: cardinal] returns [boolean] = 

BEGm RET\JRt^[group[first].age< group[second]Mge]]EHD; 
Exchange: procedure [first, second: cardinal] = 

BEGIN 

t: PomJER TO Person: 

t ^ grouplfirst]: group\first] ^ group[second]; group[second] *- t 

end; 

Sort\first: 1, last: N, lessThan: Younger, swap: Exchange]: 
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A call statement is ordinarily used to obtain side effects. Most often, these take the form of changes 
to variables that are not local to the invoked procedure, but they may also involve input or output. 
A function may also ha\e side effects as well as return results. On occasion, only the side effects are 
important, and the user wishes to ignore the returned results. An easy way to do this is to assign the 
result record to an empty extractor: 

[ ] ♦- I[x]\ - call F and discard its result record. 

A call that supplies }w arguments is written with an empty constnictor. "[ ]". When such a call is 
itself a statement, die empty brackets may be omitted. 

A fine point: 

When the call is used as an expression, the empty brackets are mandator}-: otherwise, the value of the 
expression is the value of the procedure, not the value of its results. For example, consider the two procedure 
variables in the following: 

Procl: PROCEDURE RETURNS [INTEGER]: 
Proc2\ PROCEDURE RETURNS [INTEGER]: 

-- here the program assigns values to the procedure variables 
IF Prod = Proc2 THEN . . . - compare the procedure variables 

IF Prod [ ] - Proc2\ ] THEN ... -- compare their results (integers) 

At the time a call occurs, a specific activation is executing, the callefs activation. The effect of a call 
is to suspend execution of the caller, to create a new activation of die called procedure (including 
new storage for all parameters and local variables), and to begin execution of that activation. An 
important consequence of this structuring of procedure control is that all Mesa procedures are 
inherently capable of being recursive and reentrant. 

5.2.1. Arguments and parameters 

Arguments are values supplied at call- time: parameters are variables that are local to a given 
activation. The association of arguments with their parameters amounts to assignment, much as if 
die following were written: 

InRec\RECORD[argl\ TypeLarg2\Type2, ...]\ 
InRec <- [argl\ vail, arg2: vaI2, ... ]; - in die caller 

paraml: Typel: 
param2'. Type2\ 
[paratnLparam2, ...]^ InRec: -- in the called procedure 

This is not just an idle analogy. The semantics of assignment accurately describe how arguments are 
associated with parameters. The following are direct consequences of this: 

An argument of a procedure need only confoim to its parameter, just as for assignment. 

All arguments are passed by value in Mesa: z.a, the value of an argument, not its address, is 
assigned to the parameter. Of course, this value itself can be an address (e.g., if Typel were 
POINTER TO TypeX). 

5.2.2. Tennination and results 

A procedure terminates by executing a return statement, which constructs a (perhaps empty) result 
record. The return operation then terminates execution of the current procedure activation and 
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restarts the caller from the point at which it was suspended by the call. As part of the return, 
storage for the parameters and local variables of the returning procedure is released. 

Since the value of a procedure is its result record, the components of that record can be assigned to 
variables using an extractor; alternatively, any single component (if named) can be referenced by a 
field selector. The procedure ReturnExample returns three integer results and may be used as 
indicated: 

ReturnExample: procedure [option: [1..4]] returns [a. 6, c: integer] = 
BEGIN ... - body defined in section 5.3.1 - . . . end: 

xv,z: integer; 
case: [1..4]; 

X <- ReturnExample[case],a\ - get a component only 

[b: }\ c: z] ^ RetumExample[case]: - assign results by extractor 

X ^ (ReturnExa?nple[case]x-^ 1) mod 10; - use c component 

If a procedure returns an empty result record, the call does not have a value and can only be used 
as a statement. 

If a procedure returns a single-component result record, extraction and selection are valid. In 
addition, the component may be (and usually is) accessed directly because of the automatic coercion 
from a single-component record to its single component. In the following example, the first two 
calls of Gc^ are valid and equivalent; the third illustrates typical use within an expression: 

gcd<^ Gcd\m,n\i --(coercion) 

[gcd] ^ Gcd[m,n]\ — (explicit extraction) 

^/Pr/w^ ^ Gc^[m, 7i] = 1; >- (coercion) 

Some fine points: 

In the declaration of ReturnExample, [a, ^,^: INTEGER] defines a unique type for the result record. Because 
of the conformance rule for record types (section 3.3.2), it is impossible to declare a variable with that type. If 
a procedure is to return a record value with a particular type T, it must return a single-component record where 
that component is a record of type T. 

For similar reasons, the result record of G below is not acceptable as the argument record of F. 

F: PROCEDURE [x v: INTEGER]: 

G: PROCEDURE [/: INTEGER] RETURNS [x.v: INTEGER]: 

With these declarations, the call F[G[j]] is not legal: it would be with the following declarations: 

T: TYPE = RECORD [x. y: INTEGER}: 

F: PROCEDURE [m: T]: 

G: PROCEDURE [/: INTEGER] RETURNS [out: T]: 



5.3. Procedure bodies 

An actual procedure declaration looks like the declaration of a procedure variable followed by a 
special kind of = initialization, a ProcedureBody. The TypeSpeciflcatlon appearing in the 
declaration determines the type of the body as well as that of the procedure identifier. It may be 
any TypeSpecification equivalent to a ProcedureTC. ProcedureBody is a special form of 
initialization defined as follows: 

Initialization :: = . . . | = ProcedureBody | *- ProcedureBody 

ProcedureBody ::= IniineOption Block - see section 4.4 for Block 

InlineOption ::= empty [inline 



74 Chapter 5: Procedures 

If the attribute inline appears, the procedure body is an inline one; any call of tlie procedure is 
replaced by a modified copy of the body (section 5.6). 

Only a procedure initialized with = to a ProcedureBody is called an actual procedure: its 
meaning cannot change because it cannot be assigned to. If, however, it is initiali/xd to a 
ProcedureBody using <- initialization, its value can be changed by assignment, and it is 
considered a procedure variable. Initialization using *- is not pennitted for an inline procedure. 

In addition to other statement foiTns, a procedure body can contain return statements (described in 
the next section). There is an implicit return at the end of each procedure body if one does not 
appear explicitly. 

A ProcedureBody defines a scope for declarations; i.e., identifiers declared within it are local to 
the procedure and are unknown outside it. There must be no duplicates among the names in a 
procedure's ParameterList, ResultList and local variables. Names in the ParameterList can 
be used to write a keyword constructor (section 3.3.4) in a call of a procedure. Similarly, names in 
the ResultList ean be used in keyword extractors (section 3.3.5) and as qualifiers (section 3.3.3)* to 
access the results returned by a procedure. Within a procedure, any named fields of parameter and 
result records act just as local variables; the former are initialized with the values of the actual 
parameters. A ParameterList for an actual procedure should be a named field list so that the 
procedure body ean reference the parameters. 

A fine point: 

Although the parameters and results act as local variables within the block that is the procedure body, the 
scopes are slightly different. The scope of the named parameters and results includes any OpenCtause, 
EnableClause or ExItsClause of that block: the scope of the local variables does not (section 4.4.2). 

5JJ, REJ\JRH statements 

There are two basic forms of return statement: return and return followed by a constructor. 
When either form is executed, control returns to the point from which the procedure was called. In 
addition, the return can supply results in the form of a constructor conforming to the type of the 
procedure's ResultList: 

ReturnStmt :: = return] return [ComponentLlst] 

There may be any number of return statements in a procedure body. The form of a return 
statement depends upon the ReturnsClause in the definition of the procedure type. There are 
three cases to be considered: 

no ReturnsClause (empty result record) 
an unnamed field list as the ResultList 
a named field list as the ResultList 

If there is no ReturnsClause, the ReturnStmt must be just "return". An explicit return 
statement can be omitted at' the end of the procedure in this case. 

If an unnamed field list is used for the ResultList, each ReturnStmt must include a positional 
constructor. That constructor must match the field list exactly, with one component for every field 
{omission, elision and voiding are not allowed). In this case, there is no implied return at the end of 
the procedure. 

If the ResultList is a named field list, either form of ReturnStmt is acceptable. If no explicit 
constructor appears, the current values of the named result variables define the value of the result 
record. An explicit constructor may use either positional or keyword notation; again, omission, 
elision and voiding are disallowed. A return statement is optional at the end of the procedure; if 
omitted, an implicit return of the result variables is provided. An example follows: 
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ReluniExample'. PROCEDURE [option: [1..4]] returns [a. k c: integer] = 



BEGIN 

SELECT option FROM 



1 = > RETURN 

2 = > RETURN 

3 => return;' 

ENDCASE =>b 



a:\ 
1,2, 

-4; 



. b: 2, c: 3]; 

3]; 



end; 



keyword parameter list 
positional version of option 1 
a=^b=c=:0 



implicit return; a=0. b=4.c=9 



5.4. A package of procedures 

This section contains an example of a simple module, Binary^Tree, which is designed to create and 
manage a data base structured as a binary tree. It is typical of the ways in which related procedures 
are packaged together. The example illustrates many of the issues discussed in the previous sections 
and also introduces the use of modules and interfaces in Mesa. 

The binary tree implemented by the example is a data structure containing nodes linked by pointers. 
Any node points to at most two others (its sons\ and a node is pointed to by exactly one other node 
(its parent). A special root node exists and is referenced by a pointer not in the tree. Every node 
also contains a value, which for simplicity in the example is just an integer. When the program 
starts, the tree is empty, and any call to SeekValue will return a count of zero. 

The nodes in this particular binary tree are records with four components; 

value -- an integer value (with unspecified interpretation), 

count - the number of duplications of the value in the data base, 

left -- pointer to a "left" son node (or nil), and 

right -- pointer to a "right" son node (or nil). 

There are rules of association between the values and the nodes; 

The first supplied value is entered into the root node. 

A given value may exist in only one node; duplications are counted. 

If node E points to "left" son L, then all the values in the subtree rooted at L are less than 
the value in E. If node E points to "right" son G, then the values in the subtree rooted at 
G are greater than the value in E. 

When the module is started, the tree is initialized to be empty. Thereafter, the module itself 
executes no code, but its procedures can be called to alter the tree that it manages. For instance, 
other modules call PutNewValue to insert new values into the tree. 

PutNewValue calls another of BinatyTree's procedures, FindValue, which traverses the tree seeking a 
node that already has a given value. FindValue may find such a node, or it may fail by reaching a 
higher-valued node with a nil left son or a lower- valued node with a nil right son. If FindValue 
finds a node with the given value, PutNewValue increments that node's count. Otherwise, 
PutNewValue sets up a new node and attaches it to the node returned by FindValue. 

This strategy is chosen for simplicity, but it can be a poor way to construct a binary tree. For 
instance, if the values are entered in strictly decreasing order, the tree becomes a linear list of left 
nodes. To find the lowest-valued node, every node must be examined. 



The reader should read the explanation following the example in conjunction with the example itself. 
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Example 2. A Package of Procedures 

1: DIRECTORY 

2: Storage: from "storage" \^S\H(^ [Allocate]. 

3: OrderedTabk: from "orderedtable" using [UserProc]\ 

4: 

5: BinaryTree: PROGRAM IMPORTS Storage EXPORTS OrderedTabk = 

6: BEGIN 

7: 

8: -- type definitions and compile-time constants 

9: Node: type = pointer to BinafjNode: 

10: Bimry^Node'. type = RECORD[va/we: integer, cow/i/: cardinal, kfu right: Node]: 

11: nodeSize: CARDiHAL = s\ZE[BinafyNode]: 

12: 

13: -- a global variable 

14: mo/: Node: 

15: 

16: -- public (exported) procedures: 

17: SeekValue: public procedure [val: integer] returns [count: cardinal] = 

18: BEGIN 

19: node: Node: 

20: found: boolean; 

21: [found, node] *- FindValu^val]: -- see if it is in the tree 

22: rejurh[\f found THEHnodexount ELSE 0] 

23: END; 

24: 

25: PutNewValue: public procedure [val: integer] = 

26: BEGIN 

27: node, nextNode: Node: 

28: already InTree: boolean; 

29: -- Use F/>7(iFa/we to find where to put vfl/: 

30: [alreadylnTree, node] ^ FindValue[val]: 

31: \F already InTree IHEH nodexount ^ nodexount-{-\ 

32: ELSE BEGIN - name "external" procedure Allocateby qualification 

33: nextNode ^ Storage. Allocate[nodeSize]: 

34: nextNodef ♦■ BinafyNode[vah 1, nil, nil]; -- initialize the new node 

35: IF roo/= NIL then root ^ nextNode 

36: ELSE IF vaKnode.value then nodeJeft ^ nextNode else nodesight *- nextNode: 

37: end; 

38: end; 

39: 

40: EnumerateValues: PUBLIC PROCED\JRE[userProc: OrderedTabkMserProc] = 

41: BEGIN 

42: -- a local procedure (sec. 5.6) 

43: Walk: procedure [fiode: Node] returns [keepGoing: boolean] = 

44: BEGIN -- walk through the tree in order by increasing value using recursion 

45: RETURN [node = nil - don't examine empty (sub) trees 

46: 0R( 

47: Walk[nodeAeft] - enumerate the lesser- valued nodes first 

48: AND userProc[node.value, nodexounl] - enumerate this node 

49: AND Walk[node,right] -- then enumerate the greater- valued nodes 

50: )] 

51: Em\"OfWalk 

52: Walk[root]: - just start enumerating at the root 

53: end; 



54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
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a procedure that is private to this module 

FindValue: procedure [val: integer] returns [/// 7/*^^: boolean, node: Node] - 

BEGIN 

fiextNode: Node *- roof: -- always start at the root 

IF /t;0/= nil then RETURN [FALSE, NIL]; 

UHJ\L next Node =H\L 
DO 

node *- nextNode: 
nextNode *- select val from 

< node, value = > node. left. 

> node, value = > node, right, 

ENDCASE =>NIL; 

ENDLOOP; 

RETURN [val=node.vaIue, node] 
end; 

mainline statements 

root *- nil; -- make tree initially empty 

END. 



5.4.1. The example 

Each Une of the source code in Example 2 is numbered for convenient reference; other than that 
the code could be compiled as it stands. 

The body of a program module resembles a procedure body: begin, followed by declarations, then 
some statements, and finally end. The declarations and statements are both optional, but it would 
be unusual to omit the declarations. 

In this example, the module BinaryTree declares five actual procedures: SeekValue (lines 17-23), 
PutNewValue (lines 25-38), EnumerateValues (lines 40-53), Walk (lines 43-51) and FindValue (lines 
55-68). It also declares two types {Node and BinaryNode), a constant (nodeSize), and a single global 
variable (root). The scope of these declarations is the entire body of the module (lines 6-72). For 
example, PutNewValue, EnumerateValues and FindValue all reference the global variable root. 

When a module is created and started (chapter 7), the global variables are created and any 
statements in its body are executed. BinatyTree has just one such statement (line 71), which creates 
the initial empty tree by assigning nil to root. Storage for activations of modules is not released 
when control reaches the end of the main body. Global variables such as root continue to exist and 
may be used to retain data shared by the actual procedures in the module. 

The procedure EnumerateValues has two major distinguishing features: it takes a procedure value as 
a parameter, and it contains the declaration of a nested procedure (Walk). For each node in the 
tree, EnumerateValues calls the procedure value userProc that it received as an argument, passing it 
the value in that node and its replication count If userProc returns true, the enumeration of the 
values continues; if it returns false, EnumerateValues terminates and returns to its caller. The 
values are generated in order from least to greatest. 

The nested procedure Walk is recursive and traverses the tree by first traversing die left subtree, 
then visiting the root, and finally traversing the right subtree. This postorder traversal delivers the 
values in increasing order (the reader should convince himself that it does). The expression in lines 
47-50 depends upon the definitions of and and OR (section 2.5.3) to tenninate the traversal as soon 
as userProc returns false. The first procedure call occurs only if node is not null; the second only 
if the first is called and returns true; the third only if the first and second are called and both 
return true. Section 5.6 treats local procedures in more detail. 
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5,4.2. Invoking procedures in other modules 

71ie DIRECTORY section at the beginning of a module associates identifiers with file names. The 
identifier Storage, for example, must be the name of a (definitions) module that is stored on the 
file named "storage". Such modules allow the independent development of interface definitions and 
the sharing of such definitions. Storage and OrderedTable are said to be included by BinafjTree. 
ITie optional using clause provides compiler-checked documentation of exactly which identifiers are 
used in a module but defined in the associated interface. 

The IMPORTS list (section 7.4.1) on line 5 allows BinatyTree to access a procedure (/l//oc^/6'^ defined 
in the interface Storage, which has the following (skeletal) form: 

Storage: DEFINITIONS = 
BEGIN 

Allocate: procedure [size: cardinal] returns [pointer to unspecified]; 

END. 

The example uses explicit qualification (dot notation) to name the y4//oc^/e procedure (line 33). 

The EXPORTS list (section 7.4.3) names the single interface OrderedTable, which is defined as follows: 
OrderedTable: definitions = 

BEGIN 

- types 

UserProc: type = PROCEDURE [v(2/: integer, count: cardinal] returns [continue: boolean]; 

-- the interface 

SeekValue: procedure [val: integer] returns [count: cardinal]; 

PutNewValue: procedure [val: integer]; 

EnumerateValues: PROCEDURE [userProc: UserProc]', 

END. 

Other modules access the public procedures in BinaryTree {SeekValue, PutNewValue and 
EnumerateValues) by importing this interface (just as BinaryTree imports Storage)', they have no 
other access to Binary^Tree. For example, FindValue is private to BinaryTree, so it is only called 
from within the module (lines 21 and 30). The definition of the type UserProc is included in the 
interface so that it is publicly available for defining procedures to be passed to EnumerateValues. 
Note that BinaiyTree also obtains the definition of this type from the interface (line 40). 



5.5. Nested procedures 

Actual procedures may be declared within procedure bodies. A nested procedure is one declared 
within (and local to) some enclosing procedure. Nesting of procedure declarations restricts the scope 
of the names of the inner procedures. In addition, the enclosing procedure establishes an 
environment for the inner; this is especially useful when the inner procedure is passed as a 
parameter. 

The value of a nested procedure (and any activation of that value) is "tied" to the local variables of 
the enclosing procedure and, indirectly, to the local variables of the procedure or module in which 
the enclosing one is declared, etc. An activation of the nested procedure references those variables 
available at its point of declaration. A different activation of the enclosing procedure declares a 
nested procedure with a different value, one with its nonlocal variables tied to that other instance of 
the enclosing procedure. 
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ITic following example uses the interface OrderedTable defined in section 5.4 and illustrates a typical 
application of a nested procedure. 

AverageValue: PROCEDURE RETURNS [integer] = 

BEGIN 

sum. u: integer; 

AddValue: OrderedTable.JJserProc - - a nested procedure 

begin 

n ^ n -f count\ sum *- sum -f counf^vah 

return [continue: true] 

end; 

sum ♦■ n ^ 0; 

OrderedTable. Enumerate Values[ AddValue] 

RETURN [if /]= THEN ELSE (IF sunKO THEN sum - {n/2) ELSE sum + ( n/2))/n] 

end; 

The procedure AverageValue computes the average value of the value fields in the binary tree. It 
declares and initializes a pair of local variables (ai and sum) thai are updated by the nested procedure 
AddValue but must have a greater lifetime than any individual activation of AddValue. Note that a 
similar effect could be achieved by making n and sum global variables in this case; the suggested 
solution restricts their scope (and thus the opportunity for accidental misuse). 

Execution of AverageValue involves a second nested procedure, the procedure Walk within 
Enumerate Values. The lattef s parameter userProc serves a purpose similar to that of sum or n in 
AverageValue. Since there is nothing to prevent a recursive call of EnumerateValues from some 
actual procedure corresponding to userProc, making userProc a global variable in the module 
BinaryTree could be disastrous. 

A fine point: 

Because a nested procedure is tied to an activation of the enclosing procedure (even when it references no 
nonlocal variables), the value of a nested procedure should not be assigned to a variable with a lifetime greater 
than that of the enclosing procedure instance. 

In a sense, all procedures are "local" procedures. They are either local to some enclosing procedure 
or local to some module (recall that static variables are local to the module declaring them). This 
nesting can continue to an arbitrary number of levels. (The level is important only to the extent 
that it influences name scopes, a topic covered in the next section.) 

5.5.1. Scopes defined by procedures 

Each procedure body defines a new scope for names declared in that procedure. Such names 
represent variables that are local to the body. The scope for a local variable is such that: 

(1) the local variable is unknown outside of ihai procedure body, and 

(2) a non-local variable is unknown inside the procedure // its name matches some local 
variable's name. 

Within a procedure body, a block (section 4.4) can be used to further restrict the scope of a local 
variable. In the following example, scopes for the procedures are indicated by comments: 
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SomeModuk: PROGRAM = 

BEGIN 

v^r. integer; 

- the var of integer type is used here 
OuterProc: PROCEDURE = 

begin 

van boolean; 

- the var of BOOLEAN type is used here 
LocalProc: procedure = 

begin 

\w. character; 
. ... -the vjrofCHARACTER type is used here 

end; 
... " the var of boolean type is used here 

end; 

- the var of INTEGER type is used here 

END. 



5.6. Inline procedures * 

An actual procedure is said to be inlme if the attribute inline appears before the body in the 
declaration of that procedure. Any call of the procedure is replaced by an inline expansion, which is 
a modified copy of the procedure's body. The code of the procedure and any storage required for 
local variables are merged with die code and storage of the calling procedure or module. Thus 
inline procedures can be used to eliminate the overhead of a procedure call and return (usually at 
the cost of a longer object program). 

The rules for creating the expansion are defined so that the presence or absence of the inline 
attribute has no effect upon the meaning of a program. Execution of the expansion must always 
produce a result with the same logical behavior as the result of applying the following operations: 

(1) For each argument, create a uniquely named variable local to the caller, and initialize tiiat 
variable with the value of the argument. 

(2) If there is a result record with named fields, enclose the body of the inline procedure in a 
block containing a declaration of each such field. 

(3) In the resulting block, replace each reference to a field of the parameter list by the identifier 
introduced in the first step for the corresponding argument. 

Any global variables of the procedure body refer to the corresponding variables accessible at its* 
point of declaration, not the point of call. 

Some fine points: 

A catch phrase can be attached to the call of an inline procedure (section 8.2.1). The arguments are evaluated 
outside the scope of the catch phrase. 

The Mesa compiler attempts to discover many of the common cases in which "call by name" is equivalent to 
the "call by value" substitution described above. When it discovers such a case, the argument is substituted 
directly for the corresponding parameter. 

The attribute inline is never mandatory. Deleting inline is always valid, but adding it is not No 
inline procedure can be recursive, either direcdy or indirectly through a chain of inline procedure 
calls. Consider a procedure Proc declared as follows: 

Proc: PROCEDURE [v: integer] returns [integer] = INLINE 
BEGIN 
RETURN [v*V -h 3*V + 1] 

end; 
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Because of its inline attribute, Proc cannot be used in any" of the following situations: 

When Proc itself is the operand of one of tlie fundamental operations of assignment 
(procVar <- Proc. GeneratorProc[Proc]. etc.) or comparison {Proc — AnotherProc). 

When Proc itself is used as an alternative in a conditional expression, e.g., 
(IF predicate then Proc ELSE AnotherProc)\x\ 

When Proc is the operand of fork (section 10.1). 

When Proc is to be exported to an interface (section 7.4.3). 

Some fine points: 

Since arguments are evaluated before procedures are called, usage such as Proc\Proc\x^ does not make Proc 
recursive. 

Additional restrictions apply when an inline procedure is declared in a DEFINITIONS module (see section 7.3.3). 
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CHAPTER 6. 



STRINGS, ARRAY DESCRIPTORS, 
RELATIVE POINTERS, AND VARIANT RECORDS 



This chapter introduces two new data types, strings and array descriptors, discusses relative pointers, 
and also extends the definition of record types to include variant records. 

In Mesa, the type string is really "pointer to StringBody': a StringBody conidins di length field 
indicating how long the string currently is, a maxlength field giving the length of that array, and a 
packed array of characters. 

An array descriptor describes the location and length of an array. For ordinary arrays, these are 
fixed at compile-time. Values of array descriptor type, however, have location and length items that 
can vary. These array descriptors may represent arrays that are dynamic, but they may also 
represent ordinary arrays. For efficiency, users often pass array descriptors to procedures instead of 
passing the entire arrays themselves. 

Relative pointers require the addition of a tef pointer to obtain an absolute pointer. This allows 
data structures with internal references that are independent of memory location. 

Variant records contain a set of common fields and a variant portion with a specified set of different 
possible interpretations. 



6.1. Strings 

In Mesa, a string represents a finite, possibly empty, sequence of characters. Associated with a string 
are the following: 

length the number of characters represented. The length may vary at run- time (except 

for constant strings). 

maxlength the maximum length. This guarantees that the string is finite. A string's length 
may vary from zero up to its maximum length. 

text an indexable sequence of characters. 

STRING is a predefined type in Mesa. Each program contains the following relevent pre-declarations: 

STRING: TYPE = POINTER TO StringBody\ 
StringBody: type = machine dependent record [ 

length: cardinal, 

maxlength: -read only- cardinal, 

text: packed array [0..0) of character]; 
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Suppose s is a string variable, llien sJengih and sjnaxlength refer to the first two components of 
the string structure currently pointed to by s. The type StringBody is "built into" the Mesa language 
so that tlie /th character of the text array, s.text[j\, may be abbreviated s[i\. l^he index type of text 
in the declaration is used only to specify a starting index of 0. It is better to think of a particular 
STRING as having an index type [0..s.maxlength). 

The value of sjnaxlength is assigned when a string structure is created and is a constant: it may not 
appear as a LeftSide in the user's program. However, sJength can be used as a LeftSide. In fact, 
the user is responsible for setting and changing the length when appropriate (i.e., sJength is meant to 
reflect the "meaningful" length of the character sequence). Suppose, for instance, that s initially 
points to an empty string. Then the user might append characters as follows: 

s[sJength] <- anotherChan sJength ^ s.length-\-\\ 

Actually, characters are seldom appended in this manner. The recommended practice is to use string- 
handling procedures provided by the Mesa system. These are documented in the Mesa System 
Documentation and in appendix C of this manual. 

Since strings in Mesa are actually pointers to string bodies, several strings may refer to the same 
body. Therefore, a change to that structure would manifest itself in all such strings. Keep the 
following in mind: 

When an item has type STRING, think "string- pointer", 

A fine point: 

While the programmer cannot assign to the maxlength T\t\d. with an assignment statement, it can be set (along 
with the length) in a constructor, i.e. 

AllocateWords-, PROCEDURE [n\ CARDINAL] RETURNS [POINTER TO UNSPECIFIED]: 
ST. STRING: 
k: CARDINAL: 

5 <- AlIocateWords[StrmgDefs.WordsForString[k]]: 
St <- StringBodyilength: 0, maxlength: k, text'. ]: 

This is the way to initialize a StringBody when the space for it comes from some general storage allocator. 
Note that the text field cannot be set with the constructor since the ARRAY is of length zero in the declaration. 

6.LL String literals and string Expressions 

String literals are written by enclosing the desired sequence of characters in quotation marks, "...". 
A quotation mark within a string constant is represented by a pair of quotation marks (""). Here 
are some examples of string literals: 

'The first example contains 
some embedded 
carriage-returns," 

"A quote mark (') isn't a quotation mark("")..." 

..JM 

-- an empty string 

A string literal is an Expression of type string. Its value is a constant pointer to a constant 
StringBody in which: 

length = number of characters given, and 

maxlength = length 
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'ITie fundamental operations are defined for string Expressions. They deal with them as pointer 
values: e.g., ^ assigns one string pointer to another string pointer, = compares two strings for the 
same pointer value, and # compares two strings for different pointer values. 

A fine point: 

ITie bod> of a string literal is ordinarily placed in the global frame of the module in which the literal appears 
(it is copied from the code when the module is STARTed). Pointers to that bod\ (the actual STRING values) 
can then be used freeh with little danger that the body will move or be destroyed. Unfortunately, this scheme 
can consume substantial amounts of space in the (piirmanent and unmovable) global frame area. 

If a string literal is followed by 'L (e.g.. "abc"L). a copy of the string body is moved from the code to the local 
frame of the smallest enclosing procedure whenever an instance of that procedure is created. As a corollary, the 
space is freed and the string body disappears when the procedure returns. This allows smaller global frames, 
but it is important to insure that pointers to local string literals are not assigned to STRING variables with 
lifetimes longer than that of the procedure. Programmers should avoid using local string literals until 
performance tuning is necessao- (except perhaps in calls of straightforward output procedures). 

6,1,2, Declaring strings 

String variables are declared like ordinary variables, but there is one additional form of initialization 
(for strings only): 

Initialization ::= ...♦- [Expression] | = [Expression ] 

The Expression must be a compile-time constant Expression of type cardinal. At run-time. 
Mesa creates a string structure with maxlength equal to this Expression's value, length equal to 
zero, and text uninitialized. The declared string variable is then set to point to diis string structure. 
If an Id List is declared with this form of initialization, all of the listed variables initially point to the 
same string structure. 

Some examples: 

currentLine: string ^ [256]; 

stringBuffer. string ^ [stringMax-\-someExtrd\', 

This would cause allocation of two string structures in the frame of the program or procedure 
containing the declarations. The string currentLine would point to one v^hosQ maxlength is 256. 
The string stringBuffer points to the other string structure. (Note that stringMax and someExtra 
must be compile-time constants.) Since the initialization is done with "<-", it is legal to assign new 
pointer values to these string variables. 

The follbwing are examples of fixed form string initialization: 

whatWasThat; string = "Eh?"; 
goofed: string = whatWasThat\ 

In this case. Mesa would allocate and fill in a string structure for string Gonstant "Eh?". 
whatWasThat and goofed, would be compile-time constants having the same string value: i.e., they 
would both point to the same string structure. In fact, any other references to the same string literal 
will point to the same string structure. For example: 

huh: STRING = "Eh?"; 

String variables can be declared with ^ initialization or without any initialization: 

stdErrorMsg: STRING ♦- "It seems that we have made a mistake." 
firstReply, reply: string ♦• "Yes"; 
oldBuffer, newBuffer, string; 
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IF quickDialoglHEH sfdEnvrMsg *- whatWasThaf: 

\F reply[0] = l JHEt^ 

\FjlrsiRepIy[0]=^^l then HelpaLoi 
ELSE Helpa Little: 

oldliuffer*' new Buffer *- striugBufferl: 

IF stringBufferl -^ stringBuffer2 THEN newBuffer *- stnngBuffer2: 

A fine point: 

The Mesa system contains procedures you should use when allocating blocks of data. These procedures are 
helpful for applications involving an arbitrar\ number of strings or strings of arbitrary- length. The procedures 
are documented in the Mesa System Documentation. 

6.L3. Long strings * 

A STRING is just a pointer, so long string is also a predefined type: 

LONG STRING: TYPE = LONG POINTER TO StringBodyV 

It is perhaps curious to note that declaring a long string says nothing about its actual or potential 
length. 

6.2. Array descriptors 

A full description of an array contains several items of information. Consider a typical array 
declaration: 

schedule: array [1..999] OF Z)^/e; 

The following things are known about schedule: 

base = @.schedule\\], 

index type = [1..999] (a subrange of integer or cardinal), 

minlndex = 1, 

length - 999, 

component type — Date 

All of these items except base are compile time constants, and the value of base is the address of a 
fixed place in the frame, chosen by the compiler. Mesa provides a mechanism for dynamic arrays, 
where the base and length can vary at run-time. The implementation does not allow for a variable 
minlndex. Dynamic arrays are implemented by means of Array descriptors. 

6.2. L Array descriptor types 

An array descriptor type is constructed much like an array type: 

DescriptorTC :: = descriptor FOR ReadOnlyOptlon ArrayTC | 

DESCRIPTOR FOR ReadOnlyOptlon PackingOption array of 
TypeSpecification 

ReadOnlyOption ::= empty [readonly 

PackingOption ::= empty [packed 
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For example, 

evefus: descriptor for array [1..999] of Dale: 

If readonly is specified, tlie contents of the array cannot be changed via the descriptor. In die 
second fonn (where no IndexType is given) the index type is an integer subrange starting at zero. 

A value for events is an array descriptor (a record-like object containing items similar to those 
described previously for schedule except that die base is not fixed). The next declaration specifies an 
array descriptor in which the base and the length are variable: 

history: DESCRIPTOR for array of Date: 

Indexing can be used to access components of events and history as if they were actual arrays instead 
of array descriptors (see sec. 3.2.1). Since no index type is specified for history, it has an indefinite 
index type starting at zero with no specified upper bound. 

Two array descriptor types are equivalent if they specify equivalent types for their array elements 
and if they have equivalent index-sets (or if both index-sets are unspecified). Note that descriptor 
for array [0..2] OF T and descriptor for array [1..3] of T are different types, even though the 
lengths and element types are the same. Expressions of equivalent descriptor types may be 
compared for equality (= or #). 

The rules for assignment are somewhat more relaxed. If al has type descriptor for array of T, 
and a2 has type descriptor for array [0..10) of T, then the assignment al ^ a2 is legal, but the 
assignment a2 ^ al is not. 

In any case, for assignments and comparisons, both operands must be array descriptors, and it is the 
descriptors themselves, not the arrays that they describe which are the values operated on. It would 
be an error to attempt to assign events to schedule because the first is a descriptor and the second is 
an actual array. 

There are three function-like operators relevant to array descriptors: descriptor, base, and length. 
DESCRIPTOR returns an array descriptor result and has three distinct forms which are treated 
syntactically as built in functions: 

BuiltinCall :: = descriptor [Expression ] | 

DESCRIPTOR [ Exp ression , Exp ression ] | 

descriptor [ Expression , Expression , TypeSpecif iGation ] | 

BASE [ Expression ] I 

LENGTH [ Expression ] | ... 

The first form takes an argument of some array type; e.g., 

events <- descr\pi OR[schedule]\ 

The result is an array descriptor for schedule. The second form needs two arguments: 

base: pointer to unspecified - address of the minlndex component 

length: cardinal - number of components 

This form may only be assigned to an array descriptor variable which was declared without an 
explicit index type. 

In those rare situations where the compiler cannot deduce the component type of the descriptor 
from context, a form of the descriptor construct is provided which takes three arguments. The 
third one is a TypeSpecification, the component type. 
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'flic following example provides a fresh array of 64 Dales: 

Allocate: procedure [blkSize: cardinal] returns [pointer to unspecified]; 

hislofy *- DESCRiPTOR[y4//oc^/^[64*SiZE[D^/(']]. 64]; 

llie expressions base[] and length[] take one argument (of array descriptor or array type), base 
yields the base of the described array, and length yields its length. For example: 

events <- DESCR\PTOR[sclwdule]: - describe the entire array 

events ^ descriptor[base[5c/?^(/i//^], 5]; -- describe the first 5 elements 

There is no special form for constructing descriptors for packed arrays. The packed attribute is 
deduced from context. In the two or three argument form of descriptor for packed arrays, the 
second argument (the length) is the number of elements. 

It is usually more efficient to pass array descriptors as arguments, rather than arrays. Since 
arguments are passed by value, an array argument causes a copy of the entire array to be made twice 
(once to put it into an argument record, and once to copy it into a local variable in the called 
procedure). The next example shows a case in which array descriptors must be used, since passing 
by value would not work: 

SortlnPlace: PROCEDURElTable]: - sorts in situ 
Table: type = descriptor for array of integer; 
this Array: array [O.Jhis) OF integer; 
that Array: ARRfiiY[0,Jhat) OF \HTBGER\ 
anyTable: Table *- DESCR\PJOR[thisArray]: 

SortlnPlac^anyTable]: - sons thisArray 

SortInPlace[DESCR\PTOR[thatArra}]]: -- sorts that Array 

A StringBody (sec. 6.1) contains an array, text, of characters. One must be careful when constructing 
a descriptor for this array. Recall that the bounds of text are [0..0). This declaration is used since 
the actual length of text varies from string to string. For this reason, the "one argument" form 
should not be used to construct a descriptor for text, 

textarray: DESCRIPTOR FOR PACKED ARRAY OF character; 
s: string; 

textarray *- DESCRiPTOR[5./ex/]; - LEHGTH[textarra}] is incorrect 

textarray *- descriptor[base[5./6'x/], s. length]: - correct 

6,2.2, Long descriptors * 

The BASE portion of an array descriptor is essentially a pointer. Just as the language allows the type 
long pointer, it also allows the type long descriptor. The syntax is straightforward: 



TypeConstructor 

LongTC 

TypeSpecification 



... I LongTC 

LONG TypeSpecification 

... I DescriptorTC 



All the standard operations on array descriptors (indexing, assignments, testing equality, length, 
etc.) extend to long array descriptors. The type of BASE[desc] is long if the type of desc is long. The 
LENGTH of an array descriptor is a cardinal, whether the descriptor (i.e. its base) is long or short. 

Long array descriptors are created by applying descriptor[] to an array that is only accessible 
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through a long pointer, or by applying descriptor[ , ] or DESCRiPtOR[ , , ] to operands the first of 
which is long. Alternatively, when a short array descriptor is assigned to a long one, the pointer 
portion is automatically lengthened. Consider the following examples: 

y: DESCRIPTOR FOR ARRAY OF T\ ^ 

dd\ LONG DESCRIPTOR FOR ARRAY OF T: 

I n: cardinal; 

pp: LONG pointer to array [0..10) OF T: 

dd ^ DESCRiPTOR[p/?t]: - descriptor for the entire array 

J^ ^ descriptor[p/?, 5]; -descriptor for half of the array 

dd^d: - automatic lengthening 

pp ^ BASE[dd\; " base of long is long 

/7 ^ length[^^; -length is always a cardinal 



6.3. Base and relative pointers 

Mesa provides relative pointers, i.e., pointers that are relocated by adding some base value before 
they are dereferenced. Relocation has the further effect of mapping a value with some pointer type 
into a value with a possibly different pointer type. Relative pointers are expected to be useful in 
such applications as the following: 

Conserving Storage. Relative pointers can adequately identify objects stored within a zone 
of storage if the base of that zone is known from context. If the zone is of known and 
relatively small maximum size, fewer bits are needed to encode the relative pointers. Since a 
relative pointer and the corresponding base value can have different lengths, relative pointers 
can be shorter than absolute pointers to the same objects. Overall storage savings are 
possible when all the base values can be contained in a small number of variables shared 
among many different object references. 

Providing Movable Storage Zones, If all interobject references within a storage zone are 
encoded as zone-relative pointers, the zone itself can be organized to contain only location- 
independent values. Moving the zone, possibly via external storage, requires only that a set 
of base pointers be updated. 

Designating Record Extensions. Sometimes it is convenient to extend a record by appending 
information (especially variable-lengtli information) to it. Pointers stored in, and relative to 
tlie base of, the extended record provide type-safe access to the extensions. 

6.3. L Syntax for base and relative pointers 

The syntax for base and relative pointer type constructors is as follows: 

PointerTC ::= Ordered BaseOption pointer OptionaMntervalPointerTaH 

BaseOption ::= empty | base 

TypeConstructor ::=... | RelativeTC 

RelativeTC ::= Typeldentifier relative TypeSpecificatlon 

In a PointerTC, a nonempty Optionallnterval declares a subrange of a pointer type, the values 
of which are restricted to the indicated interval (and can potentially be stored in smaller fields). 
Normally, such a subrange type should be used only in constructing a relative pointer type as 
described below, since its values cannot span all of memory. 
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Ilic BaseOption base indicates that pointer values of that type can be used to relocate relative 
pointers. Such values behave as ordinary pointers in all other respects with one exception: subscript 
brackets never force implicit dereferencing (see below). The attribute base is ignored in 
determining the assignability of pointer types. 

A RelativeTC constructs a relative pointer or relative array descriptor type. The Typeldentifier 
must evaluate to some (possibly long) pointer type which is the type of the base, and the 
TypeSpeclfication must evaluate to a (possibly long) pointer or array descriptor type. 

Relocation of a relative pointer is specified by using subscript-like notation in which the type of the 
"array" is the base type and that of the "index" is the relative pointer type. Thus if base is a base 
pointer and offset is a relative pointer (to 7). the form 

base[offset] 

denotes an expression of type 7", and the value of that expression is {LOOPHOLE[base]-^offset)t. 

6.3,2, A relative pointer example 

Consider the BinaryTree example from section 5.5. In this program, an ordered table is stored as a 
binary tree. The tree is stored in the following Mesa data structure: 

Node: type = pointer to Binary^Node: 

Binary^Node: type = RECORD[value: integer, count: cardinal, left, right: Node]; 

Suppose that the BinaryNodes are allocated from a contiguous region of memory. If the 
programmer now wishes to put the current state of the ordered table on secondary storage, it is not 
sufficient to simply write out the region of memory containing the BinaryNodes\ This is because 
the data would make sense only if read back into exactly the same place in memory, a restriction 
that is difficult to live with. The difficulty stems from the absolute pointers used in the nodes. The 
problem can be solved by changing the definition of Node. If the Binary^Nodes are allocated from a 
region of type TreeZone, let 

TZ Handle: type = base pointer to TreeZone: 

Node: type = TZHandle relative pointer to BinaryNode\ 

The procedure FindValue would be written as follows: 

NuUNode: Node - <some value never allocated>; 

tb: TZHandle: 

root: Node *- NuUNode: -- list is initially empty 

FindValue: procedure [val: integer] returns [inTree: boolean, node: Node] = 
begin 

nextNode: Node ♦- root: 

\F root= NullNodeJHEH return [false, NuUNode]; 
until nextNode = NuUNode DO 
node ♦- nextNode; 
nextNode <- select val from 

< tb[node].value => tb[node].left, 
> tb[node].value => tb[node].right, 
ENDCASE => NuUNode; 

ENDLOOP; 

RET\jRN[val=tb[node].value, node]; 
end; 
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llic other procedures of BinaryTree can easily be rewritten to use the new definition of Node. The 
compiler would aid in the translation, since any unrelocated dereferencing of a Node would be a 
compile-time error. 

This new implementation of BinaryTree has the feature tliat the TreeZone could be moved around in 
memoiy, or written and read on secondary storage, and only the base pointer tb need be updated to 
reflect the new position of the TreeZone. 

6,3,3. Relative pointer types 

An unportant topic to consider is the interaction of the relative pointer constructs with the type 
machinery of Mesa. 

A Rel at iveTC constructs a relative pointer type whenever both the Typeldentifier and the 
TypeSpecification evaluate to pointer types. Let a RelatlveTC be 

Typeldentifier relative TypeSpecification, , 

where 

Typeldentifier is of type 

[long] BASE POINTER [SubRange^ TO [readonly] T^ , 

TypeSpecification is of type 

[long] [ordered] [base] pointer [SubRange^ to [readonly] T^ , 

and the brackets indicate optional attributes. Relative pointer values must be relocated before they 
are dereferenced. If base and offset are base and relative pointers respectively, offset"^, offset.field, 
etc. are compiler- time errors. 

If the TypeSpecification says readonly, a relocated pointer cannot be a Leftside. 

The base type must be designated by an identifier (rather than a TypeSpecification) to 
avoid syntactic ambiguities. Note that the form 

LONG Typeldentifier relative TypeSpecification 

does not have the effect of lengthening the base type and furthermore is always in error, 
since LONG cannot be apphed to a relative type. The type designated by the 
TypeSpecification can be lengthened (to give a relative long pointer) using the form 

Typeldentifier relative long TypeSpecification . 

Short relative pointers are never made long automatically. With respect to other operations 
(assignment, testing equality, comparison if ordered, etc.), relative pointers behave like ordinary 
pointers. In particular, the amount of storage required to store such a pointer is determined by the 
TypeSpecification. 

Some fine points: 

In some applications, there is no obvious type for the base pointer, i.e., it might not be possible or desirable to 
describe a storage zone using a Mesa type declaration. In such cases, a declaration such as 

BaseType: TYPE = BASE POINTER TO RECORD [UNSPECIFIED] 

generates a unique type that will not be confused with other base types. 

The declaration of a relative pointer does not associate a particular base value with that pointer, only a basing 
type. Thus some care is necessarv' if multiple base values are in use. Note that the final type of the relocated 
pointer is largely independent of the type of the base pointer. Sometimes this obser\'ation can be used to help 
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distinguish different classes of base values without producing relocated pointers with incompatible t\pes. 
Consider the following declarations: 

base A: Base A: 

bascB: BaseB: 

OffsctA: TYPE = BascA RELATIVE POINTER TO T: 

OffsciB: TYPE = BascB RELATIVE POINTER TO T\ 

offset A: Offset A\ 

offsetB: OJfsetB . 

If BaseA and BaseB are distinct Upes (see the preceding point), so are OffsctA and OffsetB. Expressions such 
as baseA[offsetB] and offset A <- offsetB are then errors, but base A[off set A\ and baseB[oJfsetB] have the same type 
(7). 

The base type must have the attribute BASE. Conversely, the attribute BASE always takes precedence in the 
interpretation of brackets following a pointer expression. Consider the following declarations: 

p: POINTER TO ARRAY IndexType OF ...: 

q: BASE POINTER TO ARRAY IndexType OF 

The expression p[e] will cause implicit dereferencing of p and is equivalent to pt[e]. On the other hand. q[e] is 
taken to specify relocation of a pointer, even if the type of e is IndexType and not an appropriate relative 
pointer type. In such cases, the array must (and always can) be accessed by adding sufficient qualification, e.g., 
^t[e]: nevertheless, users should exercise caution in using pointers to arrays as base pointers. 

Mesa currently supplies no special mechanisms for constructing relative pointers. It is expected that 
such values will be created by user-supplied allocators that pass their results through a loophole or 
from pointer arithmetic involving loopholes. 

6.3,4. Relative array descriptors 

A RelatlveTC constructs a relative array descriptor type whenever the Typeldentifier evaluates 
to a pointer type and the TypeSpecification evaluates to an array descriptor type. Let a 
RelatlveTC be 

Typeldentifier relative TypeSpecification, 

where 

Typeldentifier is of type 

[long] base pointer [SubRange^^] to [readonly] T^ , 
TypeSpecification is of type 

[long] descriptor for [readonly] array r. OF r^ , 

and the brackets indicate optional attributes. Relative array descriptor values must be relocated 
before they are indexed. The relocation yields an expression with type 

array r. OF T^ . 

Relative array descriptor types are entirely analogous to relative pointer types; indeed, values of such 
types can be viewed as array descriptors in which the base components are relative pointers. If the 
TypeSpecification says readonly, the relocated array (or its elements) cannot be a Leftside. 

In the constructor of a relative array descriptor type, the TypeSpecification must evaluate 
to a (possibly long) array descriptor type. 

In the notation introduced above, a reference to an element of the described array has the 
form 
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base[offsef][i] 
where / is the index of the element. 
Currently, relative array descriptors must be constaicted using loopholes. 

6.4. A'ariant records 

Section 3.4 discussed "ordinary" record types, where every record object of a single type has tlie 
same number and types of components. Such records are not always adequate for programming 
applications. For example, in the symbol table for a compiler, all the records could have certain , 
components in common: some standard linkage, a string representing the symbol, and a category 
field indicating whether the symbol stands for an operator, constant, variable, label, etc. Different 
categories of symbols would then need further components that were not the same in all the records. 

Variant records are designed for such applications: a variant record consists of an optional common 
pari followed by a variant part. The common part contains components that are common to all 
records of tiiis type. The variant part contains the components of each variant of the record. 

The specification of a variant record type has the outward appearance of an ordinary record 
specification: RECORD[field list]. If the record has any common components, these are specified first; 
then the variant part is specified. (The next section shows how this is done.) 

The variant part really represents a set of alternative extensions to the common part. The record 
type as a whole can be viewed as follows: 

Common Part Variant Part 

Field list for the common part -— |-— field list for variant 1 

]-— field list for variant 2 
I--... 
|-— field list for variant n 

Each individual variant is identified by one (or more) adjectives. Suppose defined record type 
DeRec is declared to have a set of variants named classL class2, and classS. Then variables could be 
declared as follows: 

someClass: DeRec; -- sometimes one class, sometimes another 

firsiClass: classl DeRec\ " sivkily a classl DeRec 
secondClass: class2 DeRec\ - strictly a classl DeRec 
thirdClass: classS DeRec, -- strictly a class3 DeRec 

Types like classS DeRec are bound variant types, DeRec and class3 DeRec are both type 
specifications, but the latter is bound to a particular variant. A variable which is declared as a 
bound variant contains a definite variant; these components can be accessed as if they were common 
components. 

The field list for any variant may, itself, have a variant part (and a variant in that part may have its 
own variant part, etc.). It is possible to have a type like small classS DeRec (i.e., the field list for the 
classS variant has a variant part which, in turn, has a small variant). 

The record, someClass, presents a problem. During the course of execution, someClass might 
contain a classl, class2, or classS variant record. (Mesa allocates enough storage to hold the largest 
variant specified for DeRec type records.) The problem is to determine which variant applies at a 
given time. 



Mesa Language Manual 93 

R) decide which kind of variant a record object contains, some form of tag is needed. This tag can 
be specified as part of the record, in which case every such record object will contain an "actual tag" 
denoting the variant it represents. Instead of storing a simple tag, it may be possible to "compute" 
the tag value whenever it is needed (possibly by inspecting some values in tlie common part). Such 
computed tags are much less safe than explicit ones. For instance, you could refer incorrectly to a 
''classT component of someClass when it held a classl variant record. The result would be 
undefined. 

It is possible to construct an entire variant for the variant part (sec. 6.4.3) by qualifying a constructor 
(for that variant) with the variant's name (an adjective, in other words). Suppose for example that 
DeRec has common components cl and c2 followed by a variant part named a^/?, and that the classl 
variant has components x and y. Then the record constructor below constructs an entire classl 
variant: 

DeRec[cl: vail, c2: val2, vp: classl [x: val3,y: val4]] 

Components of an unbound variant can be accessed using the record's tag value (whether actual or 
computed). A variation of select beginning with the keyword with is used for this purpose (sec. 
6.4.4). An example follows (given that DeRec has a computed tag): 

\N\TH someClass SELECT currentTag FROM 

classl = > Stmt'l: -- someClass is a bound classl variant here 
class2 = > Stmt'2[ - someClass is a bound class2 variant here 
class3 =>Stmt-3\'- someClassis abound classSvananihcvQ 
endcase; 

6.4. L Declaring variant records 

Variant records, like ordinary records, are usually declared in two steps: 
identifier : type = RecordTC ; -■ define record type 

IdList : Typeldentifier Initialization ; - declare the records 

Initialization for variant records (sec. 6.4.3) is similar to that for ordinary records. The (now 
complete) definition of RecordTC follows. It extends die partial definition given in section 3.4.2 
and includes machine-dependent record types: 

RecordTC ::= MachineDependent record [VariantFieldList] 

MachineDependent 

:: = empty | machine dependent 

VariantFieldList :: = CommonPart identifier: Access VariantPart | 

VariantPart | 

NamedFieldList | 

UnnamedFieldList | 
CommonPart ::= empty | 

NamedFieldList , 

VariantPart ::= select Tag from 

VariantList 

ENDCASE 

Access ::= empty | -- see section 7.4. 

PUBLIC I 

PRIVATE 

Tag :: = identifier : Access TagType | 

COMPUTED TagType I 

OVERLAID TagType 
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TagType :: = TypeSpecification | * 

VariantList :: = Variant | VariantList Variant 

Variant ::= IdUst =>[ VariantFieldList ] , | 

IdList =:>NULL, 

'The TypeSpecification in TagType must be equivalent to some enumeration or enumerated 
subrange type. If the CommonPart is not empty, it must be a NamedFieldList. If there is no 
CommonPart, the VariantPart itself need not be named. 

The following example shows many of the possible variations resulting from the above syntax 
definitions. It is unnecessarily complex for the application, but does show a number of features. It 
would be worthwhile to parse the declaration yourself using the definitions given above. The 
example might be used to describe the various "accounts" in a bank; there would supposedly be a 
table of such entries, one per account. 

Sefyice: JyPE = {savings, checking, depositBox}', 

Account: TYPE = BECORD 

I : 

number, cardinal, 

specifics: select type: Service from 

savings => [term: [30.365], intRate: PerCent, balance: Money], 

checking => 

[ 

balance: Money, 

monthlyFee: SELECT COMPUTED {free, no tfree] FROM 

notfree =^> [monthlyFee: Money], 

fiee =>NULL, 

ENDCASE 

depositBox = > \fee: Money, dueDate: Date, paid: boolean], 
ENDCASE -- no variant can be attached to the endcase 

Each arm of a VariahtPart specifies a single variant, even if a list of adjectives precedes the " = >". 
An arm may specify .null (as in the case of di free checking Account) \f \hdit ydiXidiVii needs no 
components of its own. Note that all the arms, including the final one, must end with a comma. 

The adjectives are identifier constants from some enumeration. Their type can be given explicitly, or 
implicitly as an enumeration whose members are the adjectives used in the variant part. In any case, 
the enumerated type is the "tag's" type for a variant part. There are three possible forms for the 
tag, and they represent: 

an actual tag with an explicit enumerated type (e.g., typem Account), 
an actual tag implicitly defined (e.g., easyTag in NoCommon below), or 
a computed tag (e.g., the monthly Fee for a checking Account). 

If an actual tag is used, it is allocated in the common part of the record and may be accessed and 
used like any odier common component, but it may not appear as a LeftSide, smc^ that would 
compromise the type- safeness of such variant records. Not all possible values from the tag's 
enumeration type have to be used in a variant part; some may be omitted. 

An asterisk, "*", is used to indicate that the type of an actual tag is being defined implicitly by the 
set of adjectives naming the variants in that tag's variant part. For example, consider the record 
declaration below: 
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NoComnwn: type = record 



[ - no common part 

variaiuPart: SELECT easvTag: * from 

/ => [co//?/?/: integer], 

/; k => [x, compi: string], 

endcase]; 

Hic implicit type of easyTag is {ij.k}: note: you can't declare variables of the same type as easyTag. 

Computed tags are always unnamed. In fact, they are not really tags at all: when one needs to know 
which variant a record with a computed tag contains, some computation must be done. Exactly how 
the variant "tag" is computed is strictly up to the program using it. For instance, to determine 
whether a checking Account was free or not, the program might look at some property of the 
Account number (such as whether it was odd or even). 

An OVERLAID tag is a special case of a computed tag. The differences occur in the ways in which 
fields of the record are accessed. See section 6.4.4. 

A fine point 

Special care must be exercised when declaring a MACHINE DEPENDENT variant record. Recall that MACHINE 
DEPENDENT records can contain no "holes" between fields. For variant records, this leads to the following 
rules: If the minimum amount of storage required for each variant is a word or less, each variant must be 
"padded" to occupy the same number of bits as the longest. Otherwise, each variant must occupy an integral 
number of words. 

6,4,2, Bound variant types 

The declaration of a variant record specifies a type, as usual. This is the type of the whole record. 
The variant record type, itself, defines some other types: one for each variant in the record. 
Consider the following example: 

StreamType: type = {disk, display, keyboard}', 
StreamHandle: type = pointer to Streams- 
Stream: type = record 

[Get: procedure[S treamHandIe]RETURHS[Iteml 
Put: PROCEDURE[StreamHandle, Item], 
body: SELECT type: StreamType from 
disk=> 

[file: FilePointer, 
position: Position, 

SetPosition: procedure[pointer to disk Stream, Position], 
buffer: select size: * from 
short =>[b: Short Array], 
long =^>[b: Long Array], 
ENDCASE 

I 

display = > 

[first: DisplayControlBlock, 
last: DisplayControlBlock, 
height: ScreenPosition, 
nLines: [0..100] 

I 

. keyboard =y HULL, 

ENDCASE 

]; 
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ITie record type has tlircc main variants: disk, display, and keyboard. Furthermore, the disk variant 
has two variants of its own: short and long, llie total number of type variations is therefore six, and 
they are used in the following declarations: 

K Stream: 
rDisk: disk Stream: 
rDisplay: display Stream: 
rKeyb: keyboard Stream: 
rShort: short disk Stream: 
rLong: long disk Stream: 

ITie last five types are called bound variant types. The rightmost name must be the type identifier 
for a variant record. The other names are Adjectives modifying the type identified to their right. 
Thus, disk modifies the type Stream and identifies a new type. Further, short modifies the type disk 
Stream and identifies still another type. Names must occur in order and may not be skipped. (For 
instance, short Stream would be wrong since short does not identify a Stream variant.) 

The formal definition of Typeldentifier can now be completed (it is only partially defined in 
Section 2.6.1): 

Typeldentifier :: = ... [Adjective Typeldentifier 
Adjective ::= identifier 

where Adjective is an adjective of the variant part in the type specified by Typeldentifier. Note 
that the recursive use of Typeldentifier in the first line allows a sequence of adjectives. 

6.4.3, Accessing entire variant parts, and variant constructors 

This section considers accesses to entire variant records (e.g., for initialization), common components 
of the record (including an actual tag, if present), and the variant part of the record as a whole. The 
next section covers accesses to individual components in a variant part. 

The common parts of each of the variations of a Stream declared in the previous section can be 
accessed by the normal means (qualification and extraction): 

rDisk *" rLong: " aggregate access 

rDisk.Get*- rShort.Get: - selector access 

r.body ^ rDisplay.body: - selector access 

[rDisLGet, , rDisk.body] *• rLong: -- extractor access 

The actual tag, type, in the body variant part may also be accessed by qualification: 
\f r,type=StreamType[keyboard\lHEHStmt'l: 

It is also possible to construct values of a variant record type. The syntax of a constructor for a 
variant part is no different than a normal constructor except that the identifier preceding the "[" 
must be present and must be one of the adjectives used in defining the variant For example, some 
of the following declarations use constructors to initialize the variables (others use different forms of 
initialization): 

myDisplay: display Stream *• [myGet, myPut, display [dl\d,h,S]]: 

yourDisplay: display Stream *- myDisplay: 

currents tream: Stream ^ myDisplay: 

5: Stream ^ [SysGet, SysPut, disk [fp, 0, SysSetPos, long [al] ] ]; 
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ITie keyboard variant of Stream is a null variant: so there are no coinponents for that variant in a 
keyboard constructor: 

rKeyb <- Stream[Get\ Kget, Pun KpuL body: keyboard[]]: 

A side effect of assigning a bound variant value to a variable is that the actual tag of the record is 
also changed. This is the only way to change the variant contained in a variable (except in the case of 
a COMPUTED tag) " it ensures type-safeness. For example, both the following assignments change the 
type tag for r : 

nbody ^ keyboard []: 

nbody ♦- rKeyLbody\ -- always a keyboard variant 

If one is assigning a completely bound variant value, &v, say (which could be a constructor, of 
course) in an AssignmentExpr (section 2.5.4.), then the type of the AssignmentExpr is the type 
of 6v, not the type of the LeftSide, which might not be a bound variant. 

A fine point: 

The Mesa compiler does not currently allow an entire variant part to occur on the right of an assignment as in 
the fragment above. Thus, the only way to assign to an entire variant part is via a constructor, not by copying 
the variant part of an already initialized record. This restriction should be lifted in a later release of Mesa. 

6 J. 4, Accessing components of variants 

When a record is a bound variant, the components of its variant part may be accessed as if they 
were common components. For example, the following assignments are legal: 

rDisplayJast ^ r Display. first\ 
rDisKposition ♦■ rShort,position\ 

If a record is not a bound variant (e.g., r in the previous section), the program needs a way to decide 
which variant it is before accessing variant components. More importantly, however, this must be 
type-safe. For this reason, the process of discriminating among possible variants and then accessing 
within a variant part is combined in one syntactic form, called a discrimination, which is a 
generalization of select. 

A discrimination closely mirrors the form of select used to declare a variant part. However, the 
arms in a discriminating select contain statements or Expressions, and, within a given arm, the 
discriminated record value is viewed as a bound variant. Therefore, within that arm, its variant 
components may be accessed. The following syntax equations complete the earlier partial definitions 
given in sections 4.3.1 and 4.3.3: 

SeiectVariant :: = with Openltem select Tagitem from 

ChoiceSeries 
ENDCASE FinalStmtChoice 
|... 

ChoiceSeries ::= AdjectiveList => Statement ; | 

ChoiceSeries AdjectiveList => Statement ; 

Tagitem ::= empty | -the actual tag is used 

Expression -- compute the tag value 

FinalStmtChoice :: = empty | => Statement 



98 Chapter 6: Strings, Array Descriptors, Relative Pointers, and Variant Records 

SelectExprVarrant ::= with Openltem select Tagltem from 

ChoiceList 

ENDCASE => Expression 
|... 

ChoiceList ::= AdjectiveList => Expression , | 

AdjectiveList => Expression , ChoiceList 

ChoiceList ::= AdjectiveList => Expression ,j 

ChoiceList AdjectiveList => Expression , 

Openltem ::= Expression | AiternateName : Expression 

-- from sec. 4.4.2 

The value discriminated is the one given in the with clause, which behaves just like an open clause 
(sec. 4.4.2) to simplify naming the record value in the arms of the select. The following example 
discriminates on r: 

WITH S/to: r select FROM 

display = > 

begin 

strm.first^ strfn.last\ 

stnn, height^! 3i 

strm.nLines^A\ 

end; 
disk = > WITH strm SELECT from 

short =>6[0]^10; 

long =>6[0]^100; 

endcase; 
ENDCASE => strm,body ^ disk [Get Fp["Alpha''l 0, SysSetPos, short[]]\ 

In the first example, suppose r contains a variant record of display Stream type. Then the first arm 
is chosen by this select. Within it, stmi (but not r) is considered a record of display Stream type; 
so all components of the display variant may be accessed in the statement chosen by that arm (as 
they are in the example). 

Suppose /-contains a variant record of disk Stream type. Then the actual tag has the value disk, and 
the second arm is chosen. In this example, only one of the disk components is accessed, its variant 
part. The inner select uses variant record strm. Within the outer arm. Mesa knows that strm is a 
record of disk Stream type. Consequently, the tag implicitly used for this select is the tag specified 
for that type (namely, size). 

If the tag value is short, then the chosen arm accesses component b in the short disk Stream variant 
record; if it is long, then the chosen arm accesses component b in the long disk Stream variant 
record. 

However, the endcase for the inner select could have accessed components that are common to a 
disk Stream (file, position, SetPosition, variant part buffer, and actual tag size', plus all the original 
common components: Get, Put, variant part body, and actual tag type). 

Suppose, lasdy, that r does not contain a variant record of display Stream or disk Stream type. Then 
the outer endcase statement is chosen. This statement accesses the common component body (the 
entire variant part is considered a common component), and gives the record a specific variant type 
(short disk Stream) by wholesale assignment. An endcase may only access common components; it 
may not access components of variants in the given type. 
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If the labels on an ami of a descrimination identify more than one variant stmcture, the record is 
not considered to be discriminated within that arm and only the common fields are accessible (cf 

ENDCASE). 

Since the outer variant part of Stream was declared using an actual tag, the tag s value is obtained 
from the record itself, and no Expression follows the keyword select (both selects above have 
til is form). 

Hie Expression in the with clause (actually in the Openltenn) must represent eitlier a variant 
record or a pointer to a variant record (e.g., r in the above). The alternate name is essentially a 
synonym for that Expression (e.g., stnn in the above). If it is a pointer, however, the alternate 
name designates a record value, not a pointer yalue in each arm of the select. In the following 
example, the display arm is correct, and the disk arm is in error: 

rp\ StreamHandle\ 

proc: PROCEDURE [StreamHandle]', 

WITH sRec: rp select from 

display = > proc [@sRec]\ -- CORRECT 

disk => proc[sRec]; -WRONG 

ENDCASE ; 

An open item with no alternative name opens a name scope so that components can be accessed 
with implicit qualification (as in the inner select of the first example), but then no further levels of 
WITH...SELECT w5/>2g the Same record can be done within such a with...select. The type of the open 
item's Expression indicates the nature of the record's variant part, including whether the tag is an 
actual or computed tag, its enumerated type, and the names of each variant (i.e., the adjectives) in 
the variant part. 

If a computed tag had been used, the program would have to supply an Expression following 
SELECT to determine die variant. This Expression's value would have to be an adjective in the 
applicable variant part. For example, assume that tb1[i\ in the following has type checking Account 
(sec. 6.4.1); then this is a legal (if not very sophisticated) discrimination for it: 

WITH this: tbl[i] select (if {thisMumber mod 2) = iHEHfree else notfree) from 
free =>null; 
notfree => AddToBill[thisjnonthlyFee]\ 

ENDCASE; 

If a given arm of a discrimination is labelled by indentifier constants corresponding to more than 
one variant of the record, only the common fields of the record are accessible within that arm. 

The record value in a with clause must not represent a completely bound variant (which is really not 
a variant at all). For example, a valid discrimination for a disk Stream record, aDiskStream, follows: 

with aDMS/re^m SELECT FROM 
5/7or/=>Z?[0]^10; 
long =>Z)[0]<-100; 

ENDCASE; 

// would be illegal to rewrite this as follows: 

with alt\ aDiskStream select from -- WRONG! 
disk = > with alt select from 
5/2or/=>6[0hlG; 
long =>fe[0]<-100; 

ENDCASE; 
ENDCASE; 
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An OVERLAID record is a special case of a computed variant record in that tliere is no explicit tag 
field in the record. The fields of the individual variants may be accessed using a "computed" with 
construct in the same manner as a computed record. In addition, any field name of a variant that is 
unambiguous (i.e. it appears in only one variant) can be referenced without descrimination. In 
essence, the programmer is telling the compiler "When I use a fieldname, you can trust me tliat the 
record has the proper variant." Consider the following example: 

rm5/A/^: TYPE = record[ 

SELECT OVERLAID * FROM 

one => [c: character, i: cardinal, next: pointer to TrustMe\ 
two => [b: BOOLEAN, next: pointer to TrustMe\, 
/Aree->[s: string], 
endcase]; 
/: Trust Me: 

tx "legal 

t.b "legal 

/. next " illegal, both variants one and two contain such a field. 

A fine point 

In the declaration of TmstMe above, the two next fields were of the same type, but occuppied different 
positions within the reeord. Even if they did occupy the same position, one could still not refer to unext. The 
ambiguity is one of variant, not of value. 
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CHAPTER 7, 



MODULES, PROGRAMS, 
AND CONFIGURATIONS 



Large programs in Mesa are constructed by linking or binding together individual modules. A 
module is the basic unit of compilation and also the smallest, self-contained, executable program 
unit. Most of this chapter deals with how separate modules are put together to build large systems; 
i.e., it deals with programming in the large as opposed to programming in the small (which is what 
this manual has discussed so far). 

There are two fairly distinct kinds of modules. Definitions modules serve primarily as "blueprints" 
or specifications for how the parts of a system will fit together. During compilation they provide a 
common (and therefore consistent) set of definitions which can be referenced by other modules 
being compiled. The second kind of modules, called programs, contain actual data and executable 
code. Program modules can be loaded and interconnected to form complete systems. 

Mesa compiles a program module's source code (which is just a text file) into an object module. An 
object module is a binary file containing object code, symbol table information, and data structures 
to be used in connecting (also called binding) this module together with others. Compiling a 
definitions module produces symbol table information only, which may then be used in compiling 
other modules (either definitions or program modules). 



7.1. Interfaces 

An interface is a connector between programs; it allows code in one module to access parts of other 
modules—specifically, procedures, signals (chapter 8) and variables. Interfaces are defined by 
definitions modules (section 7.3). They contain declarations for public items and allows the compiler 
to check for type matching across inter-module references. The interface, considered as a record, 
also proves a convenient data structure for efficient binding together of programs. 

The procedures that implement a given abstraction are often collected in a single interface. For 
example, an interface for an allocator might consist of the names and types of the procedures for 
allocating and freeing blocks of storage, and pointers to shared blocks of storage. The data types 
required by these procedure types (for parameters and return values) are usually defined in the same 
definitions module. Such non- interface types are available for reference when compiling other 
modules, but are not considered part of the interface specified by that definitions module. 

At compile time, a program module containing calls on procedures defined by some interface must 
import the definitions module that specifies that interface. This enables the compiler to check the 
agreement of types of parameters and return values on calls from that module with their 
counterparts in the definitions module (i.e., as defined in the interface). Importing the interface at 
compile time does not, however, link the procedure references in the program module to actual 
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procedures in some other moduJe(s). That actual binding occurs later when the compiled module is 
linked witli other compiled program modules to make a system (sec. 7.7). 

Tlie actual implementation of an interface is usually provided by a single program module, although 
it may be realized by a group of modules, each supplying a part, hi any case, if a program module 
implements (all or part of) the interface specified by a definitions module, it is said to export that 
interface. The procedures and variables in that program corresponding to the ones in the exported 
interface must be type-compatible with them (sec. 5.2). l^he compiler checks tiiat tiiis is so. 

After compilation, a program module contains a set of virtual interface records, one for each 
imported interface, and a set of export records, one for each exported interface (a single program 
module can implement more than one interface). Binding a group of modules together into a 
system then involves associating virtual interface records with exported interfaces for all the modules 
in the group. 

The following definitions module, /0Z)e/5, provides a minimal (and unrealistic) interface to a 
computer terminal: 

lODefs: definitions = 

BEGIN 

- Interface definitions 

ReadChar: procedure returns [character]; 

ReadLine: procedure [input: string]; - reads from terminal into input 

WriteChaK PROCEDURE [ouput: character]; 
WriteLine: procedure [output: string]; 

lOPkg: program; 

- Non-interface definitions 

CR: character = 015C; -- an ASCII Carriage-Return character 
END," lODefs 

The interface record for lODefs is imported by the following Copier program module. The program 
reads lines from the terminal and retypes them. When die user types a line beginning with a period, 
it writes a parting message and stops: 

DIRECTORY 

lODefs: from "lODefs"; 

Copier program imports lODefs = 

BEGIN OPEN lODefs; " allows simple references to items from lODefs 

input: STRING *- [256]; - 256-character string to hold input lines typed by user 

- the mainline part of the program starts here: 

DO -- infinite loop; only left by exit 

ReadLine[inpui]\ -■ read a line into input 

IF input[G\ = \ then exit; - quit if first character is a period 

WriteLine[input]\ - otherwise copy it back to the user 

ENDLOOP; 

I4^n7eLme["End of example."]; -final output 

WriteChar[CR]\ - leave terminal on a new line 

END. - Copier 
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ITie skeleton of a module that implements the lODefs interface follows. It exports lODefs and 
IMPORTS nothing: 

DIRECTORY 

/OZ)c/i:FROM"IODefs": 

lOPkg: PROGRAM EXPORTS lODefs = 

" this module contains the actual procedures for the interface specified by lODefs. 

BEGIN 

tenninalState: {off, on, hung} ^ off - initial state of the terminal 

ReadChar: public procedure returns [character] = begin . . . end; 
ReadLine: public PROCEDURE [input: string] = begin . . . end; 

WriteChar: public procedure [oupun character] = begin . . . end; 
WriteLine: public procedure [output: string] = begin . . . end; 
END. " lOPkg 

The next step towards running the above modules as a system requires binding them together. 
Binding is the process of matching up virtual import records with real export records. 

A separate language, C/Mesa, is used to describe binding. This language has a syntax similar to 
Mesa's, but is much smaller. C/Mesa "programs" are compiled ("processed" might be more 
accurate) by a program called the Binder. The C/Mesa source code is called a Configuration 
Description (CD), and compiling one results in a Binary Configuration Description (BCD) file. An 
object file produced by the Mesa compiler is actually a very simple BCD containing just one 
module's object code and binding information. 

BCD files can be loaded and run. (Actually, it is the individual modules in the BCD that are 
loaded). This loading also alters all the BCD's virtual import records to hold real procedure 
descriptors (sec. 5.2), signals, and pointers to program frames. Then the modules comprising the 
BCD can all be started (details in sec. 7.8). The following CD describes a system of three modules: 
Copier, lOPkg, and Driver, 

MakeCopierSystem: COHF\QURPJ\OH 

CONTROL Driver = 
begin Copier lOPkg', Driver, end. 

This configuration specifies how the Copier, lOPkg, and Driver object modules are to be bound 
together. Simply listing their names is all that is usually required in a CD. Now the Mesa loader 
could load the complete program using the BCD file for MakeCopierSystem. Driver is named as the 
CONTROL module for the BCD, so starting the loaded BCD would actually result in starting Driver, 
which follows: 

DIRECTORY 

lODefs: from "iodefs", 
Copier, from "copier"; 

Driver program imports Copier, lODefs = 

BEGIN 

START lODefsJOPkg; '- so its variables (e.g., terminals tate) are initialized 

START Copier, " to initialize its variables and run its mainline code 

END. 

This example is simple, but MakeCopierSystem and Driver would still be simple even if the system 
had 50 modules instead of just two. For this example, they seem like excess baggage, but for a 
larger system, they are invaluable because: 
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(a) tlicy describe exactly how the various modules are bound together and initialized; 

(b) C/Mesa allows Mesa's compile-time checks on types to extend to binding time; 

(c) loading and linking with this scheme can be very efficient. 

We can now give the details of Mesa definitions and program modules. Section 7.7 discusses 
C/Mesa and how it is used. 



7.2. The fundamentals of Mesa modules 

The complete syntax for a module is the following: 



CompilationUnit 

Access 

Directory 

ExportsList 

FileName 

GlobalAccess 

Imports List 

Includeltem 

Include Li St 
ModuleBody 

ModuleHead 

Interfaceitem 

InterfaceList 

LocksClause 

ModuleName 
ProgramlC 

ShareList 



= Directory -optional 

ModuleName : ModuleHead = GlobalAccess 
ModuleBody 

= empty | public | private 

= empty | directory IncludeList ; 

= empty I EXPORTS IdLlst -sec. 7.4.6 

= stringLiteral -sec. 6.1.1 

= Access -sec. 7.4.3 

= empty I IMPORTS InterfaceList 

- sec. 7.4.6 

= identifier : from FileName | 
identifier : from FileName using [ IdList ] 

= Includeltem | Includeltem , IncludeList 

= Block . -sec. 4.4 

- note the terminating period 

= definitions LocksClause ImportsList ShareList | 
ProgramTC ImportsList ExportsList ShareList 

= identifier | identifier : identifier 

= Interfaceitem | InterfaceList , Interfaceitem 

= empty | -sec. 10.4.1 

LOCKS Expression | 
LOCKS Expression using identifier : TypeSpecification 

= identifier 

= PROGRAM ParameterList ReturnsClause | 
MONITOR ParameterList ReturnsClause LocksClause 



:: = empty | shares IdList 



sec. 7.4.6 



A DEFINITIONS module can serve a twofold purpose: it can define an interface, and may contain 
declarations of constants and types. Definitions modules are further discussed in section 7.3. 

The text of a program module 1" implicitiy defines a frame type, FRAMEfA"]. Values of this type are 
created dynamically by loading X and can only be accessed indirectly; i.e., a program may have 
variables of type pointer to frame[J], but never of type frame[J]. A module's frame contains 
storage for its variables, along with some system overhead. 

We will first deal with the initial syntactic unit which is common to all modules (the Directory 
clause), then with definitions modules as a whole. After these sections there is a complete example 
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including 

a DEFINITIONS modulc. 

a PROGRAM modulc thai implements it, 

a client program that uses it, and 

a configuration that binds the programs together into a system. 

1.2.1. Including modules: the DIRECTORY clause 

llie source code for a given module may tell the compiler to include previously compiled modules 
for one or more of the following reasons: 

It might need to use some of the symbols defined by those modules. 

It may need to import die interfaces defined by those modules. 

It might refer to instances of such modules after they are loaded in order to start them, to 
make new^ instances of them, or to access their data. 

Suppose module A is included in module B. This means that when compiling J?, die compiler must 
have access to ^'s object file (i.e., A must have been compiled previously) in order to access its 
symbol table to obtain information needed by B. Warning: including a module is not simply an 
insertion of text from one module into another— it is important to read these sections carefully to use 
this capability correctly. 

The following is a simple, but complete definitions module: 
SimpleDefs: definitions = 

BEGIN 

li?nit: integer = 86; 

Range: TYPE = [ — limit..limit]\ 

Pair, type = RECORD[/?r5/, second: Range]: 

PairPtr: type = pointer to Pain 

END. 

Suppose that the above source code is contained in a file named "SimpleDefs.mesa". After 
compilation, anyone who has a copy of the object file for SimpleDefs (which will be named 
"SimpleDefs.bcd" by the compiler), may then include it in otlier modules. The ".bed" portion of 
die file name stands for Binary Configuration Description (sec. 7.6.3) of which a compiled module is 
the simplest example. The ".bed" part of the name need not be specified in the directory section 
(see below). 

A module that includes other modules begins widi a Directory, which performs two functions: 

(1) It associates a Mesa identifier with the name of an object module (which does not 
necessarily look like a Mesa identifier). 

(2) It checks that the given identifier matches the ModuleName in the module whose object 
file is named. 

Here is an example of a directory: 

directory 

SimpleDefs: from "simpledefs", 
SiringDefs: from "stringdefs"; 
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7. 2. 1. 1. Kfiwnerating items from an included module: the USING clause 

A module may list the symbols it expects to access from an included module in the using clause of 
an Includeltem. If a using clause is present, it must list all of the symbols to be included; the 
compiler will not allow access to any symbol not in die list. Warnings will be issued for symbols 
appearing in the list which are not referenced in the module. In this way, the using clause 
accurately documents which symbols are defined in each included module. 

Here is an example of a directory with a using clause: 

DIRECTORY 

SimpleDefs: from "simpledefs" using [Range, Pair], 
SiringDefs: from "stringdefs"; 

A module with this directory statement would be allowed to use the symbols Range and Pair 
defined in SimpleDefs, but would not be allowed to use any other symbols defined in SimpleDefs. 
Access to symbols defined in SiringDefs is not restricted. 

The USING clause only allows and restricts access to symbols. Actual references to the symbols must 
be made in one of the ways described below. 

7.2.2 Accessing items from an included module 

This section describes the ways of accessing symbols defined in an included module: 

An identifier, p, defined in a definitions module, Defs, can be named in an including module. User, 
in one of two ways. 

Explicit qualification: p can be named as Defs.p in User 

OPEN clauses'. In the scope of an open clause of the form "open Defs'\ the simple name p 
suffices. 

The remainder of tiiis section gives more detail on these methods. 

7.2.2.L Qualification 

In the following example, qualification is the only access method used: 

DIRECTORY 

SimpleDefs: from "SimpleDefs"; 
TableDefs: definitions = 

BEGIN 

limit: integer = 256; -- this has no connection with SimpleDefsJimit 

Index: type = [0.. limit): 

StringTable: type = array Index of string; 

PairTable: type = array Index OF SimpleDefs,Pair\ 

END. 

SimpleDefs. Pair means "the item named Pair in SimpleDefs'' As a rule, qualification provides more 
readable code than do the other methods for specifying the use of predefined symbols. However, it 
can be inconvenient if there are many such occurrences because two identifiers have to be written 
instead of one. 

No names are included automatically when only explicit qualification is used. For example, if 
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TableDefs had not declared limit. Mesa would not have used the one in SinipIeDefs. An error would 
then result when TableDefs was compiled (because limit is needed in the declaration of the type 
Index). 

Any module tliat includes TableDefs ma\ use only the symbols defined by it, but to use Pain that 
module would have to include SimpleDefs (as in the next section's example). Declared symbols in 
tlie included module do not include record component names: they are part of a record's type 
specification and can be used wherever the record type is known. 

A qualified name may denote a type defined in an included module (e.g., the type SimpleDefs,Pair 
in die example in the previous section). Thus the syntax for Typeldentifier includes the case 

Typeldentifier ::= ... | identifier . identifier 

7.22.2 OPEH clauses 

The following program, TableUser, includes both SimpleDefs and TableDefs. It accesses names from 
SimpleDefs by qualification, but uses an open clause to access items from TableDefs: 

DIRECTORY 

SimpleDefs: from *'simpledefs" using [Pair], 
TableDefs: from "tabledefs" ; 

TableUser: program = 

BEGIN OPEN TableDefs: - (Notice the OPEN-clause.) 

vindex: integer ^ limit: - this is TableDefsAimit because of the open 

vString: StringTable: 

vPair, PairTable: 

StoreSlring: public PROCEDURE[r string, v: Index] = 

BEGIN 

vString[v] *- s: 
vPair[vIndex^\] ^ NIL; 
end; 
StorePair: public procedure[/: SimpleDefs.Pair] returns[o^: boolean] = 

BEGIN 

ok *- vindex < = limit: 

IF o^THEN vPair[vlndex] ^ /; 

end; 

END. 

In the scope of the open clause, the names limiu StringTable, PairTable, and Index are those in 
TableDefs. The scope of tliese open clauses follows the same rules as the open clauses for records 
described in section 4.4.2. In fact, a single open clause can contain Openltems that open either 
modules or records. 

TableDefs could have been in an open clause anywhere that one is permitted. This feature can be 
used to help the readers of a program. For example, if the names from TableDefs were only needed 
in the procedure StoreString, we could put an "open TableDefs'' on its begin rather than on the 
BEGIN for the whole module. This would localize the region of die program where a reader would 
have to consider whedier an identifier is from an included module or not. 



Fine point: 



Note that qualification is still required to reference SimpleDefs. Pair even though Pair appears in the USING 
clause. 
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1.23. Scopes for identifiers in a module 

'llie use of identifiers appearing in modules falls into two broad categories, defining occurrences (e.g., 
to the left of the ":'* in a declaration), and no}7ie references (such as the appearance of a name in an 
Expression). Scope mies detennine which defining occurrence goes with a given reference, hi 
Mesa, these rules arc lexical i.e., they depend only on tine textual structure of the module at 
compile-time. 

A name scope is always a contiguous region of a module (e.g., everytliing between a begin... end 
pair, or between a [... ] pair) and may contain other scopes nested within it. The first scope rule is 
tlie following: 

Within a single scope (excluding scopes nested within it), there can be at most one defining 
occurrence of a given identifier. 

An important corollary of this rule is that a given identifier is either undefined in a scope or it has 
exactly one meaning. 

A qualified name reference demands an exact context for its qualified identifier. For example, 

SimpleDefs.Pair -- (sec. 7.2.2.1) qualification by module name: context is SimpleDefs 

rDisk. Get - (sec. 6.3.3) record qualification; context is disk Stream, the type of rDisk 

winner.party -- (sec. 3.4) pointer qualification; context is Person, the reference type of 

winner 

The rule of scope is simple for a qualified reference: 

The qualified identifier is associated with its symbol definition in the specified scope (if 
there is no such defined name, the qualified idendfier is undefined and there is an error). 

An unqualified name reference occurs within a sequence of nested scopes (as indicated below). The 
rule of scope is 

Use the innermost scope that defines the referenced identifier (if none of the scopes do so, 
the identifier is undefined and there is an error). 

New name scopes are created by the following: 

OPEN clauses 

Blocks with declarations 

enumerated types and their subrange types 

record types that use named field lists 

procedure types that use named parameters or results 

actual procedures 

exit regions for loops and compound statements 

the heads and arms of discriminating SELECT statements 

OPEN clauses may introduce multiple name scopes, which are nested (inner-to-outer) in order from 
right to left. Consider the following revision of the earlier TableUser module: 
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DIRECTORY 

SimpIcDefs: from "simpledcfs", 

TableDefs: from "tablcdefs"; 
TableUser. program = 
BEGIN OPEN SimpIcDefs, TableDefs: 

StorePair. public procedure[/: Pah] returns[o^: boolean] = 

Notice that we no longer need qualification for the parameter type of procedure StorePair. When 
the compiler encounters identifier Pair, it finds the needed symbol definition in the symbol table for 
included module SimpleDefs. The path by which it found this is the following: it looked for such a 
definition in the current module, but failed there; it then tried the next outer scope, which according 
to the open was TableDefs: not finding Pair there either, it went on to the next (and outermost) 
scope gi\'en by the open, namely, SimpleDefs, at which point a defining occurrence was found. 

Localizing the scope of identifiers from included modules is so important diat we recommend the 
following naming guidelines: 

(1) Place a using clause on items in the directory. This collects in one place a list of all 
symbols referenced from each included module. The list is always accurate because the 
compiler checks it on each compilation. 

(2) Use explicit qualification as the normal way of naming an external item. 

(3) Use an open clause on the smallest possible scope when explicit qualification becomes too 
verbose. It is unusual for items from an included module to be accessed with high 
frequency everywhere in a module; most often, there are clusters of references to them. An 
OPEN clause takes advantage of this clustering and alerts a reader to it. 

7.2,4. Implications of recompiling included modules 

Consider a set of modules Adefs, Userl, and User2 where Adefs is included in Userl and User2. 
(For simplicity, assume Userl and User2 include only module Adefs.) Suppose Adefs and Userl 
have already been compiled, but before User2 is compiled, Adefs is recompiled for some reason. 
Then Userl must also be recompiled. 

In general, recompiling Adefs will invalidate the current version of Userl. This is obvious when 
Adefs undergoes significant change between compilations, but it may also be true when seemingly 
innocuous changes are made. In fact, if Userl uses record or enumeration types defined by Adefs, 
the current version of Userl is invalidated when Adefs is recompiled, even if no changes are made to 
its source code! 

For example, suppose Adefs defines record type Account which is used by Userl as the type of rl 
and by User2 for r2. Normally, one would expect these records to have the same type. If events 
occur as follows, however, they will not: 

^^e/s is compiled. 

Userl is compiled including (old) Adefs. 

.4rf^/s is recompiled. 

User2 is compiled including (new) Adefs. 

The record types for rl and r2 will differ because of the way Mesa guarantees uniqueness for record 
types. The compiler associates a "time stamp" (e.g., time of definition) with each record type. Old 
Adefs defined Account at one time and new Adefs defined it a later time; this makes them different 
(non-equivalent) record types which only "look" the same. 
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Consider the case where Defsl is included in Defsl, and Defs2 is included in Userl. (For simplicity, 
assume that Defs2 includes only Defsl and Userl only Defs2.) Suppose that Defsl is recompiled and 
tlien Defs2 is recompiled. Then Userl should also be reeompiled. The reason for this is the 
uniqueness of record types defined in Defs2 and used by Userl. 

The (re)compilations of DefsL Defs2, and Userl must occur in a specific order: first Defsh then 
Defs2. and finally Userl. Suppose, however, that Userl included Z)^^2 plus anodier module Defs3. 
and suppose Defs3 included Defsl. The following diagram illustrates these dependencies. Modules 
which are included are above modules which include them. The mle for avoiding errors due to 
incorrect compilation order is the following: a module may not be (re)compiled until all the modules 
above it have been. 




Thus, Userl should be recompiled after Defs2 and Defs3 have both been (re)compiled. The order in 
which Defs2 and Defs3 are compiled is unimportant, however. Moral: There is an important partial 
order defined on modules by their inclusion relations. 



7.3. DEFINITIONS modules 

Generally, a definitions module contains a set of related definitions. There are compile-time 
constants, types, and procedure and signal definitions. There are also declarations of so called 
interface variables (section 7.3.1). These definitions are used by the program(s) that implement those 
procedures, and they are used by programs that only wish to call on those procedures. Separating 
definitions from implementations allows programs that call those procedures to be independent of 
changes in implementation. The definitions in a definitions module fall into two classes: 

Interface elements: definitions for interfaces (procedures, signals, programs and interface 
variables), and 

N on- interface elements: compile-time constants (this includes type definitions) 

There are no special rules about which valid compile-time constants may be used other than the 
issues surrounding compilation order (sec. 7.2.4). External interface definitions, however, are 
different. Normally, a declaration such as 

SampleProc. PROCEDURE [/: integer]; 

declares a procedure variable. In a definitions module, however, its effect is to define \ht type and 
name of a procedure component of the interface specified by that definitions module. Section 7.6 
contains an example of a definitions module that defines procedure interfaces. 

In the same manner, signals, errors, and programs can be declared in a definitions module as 
elements of its interface type. A signal or error declaration is treated just like a procedure as an 
interface element. A program definition as an interface element is discussed in section 7.4.3. 
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7.3,1. huerface variables 

Just as procedures are often declared in one program module and called from another, there are 
often applications that require sharing of non-procedural variables, such as common data structures. 
One means to allow common variables is via inierface variables. ITiese are variables that are defined 
in a DEFINITIONS module, but must be exported by some implementing program before they actually 
exist. X'ariable declarations in interfaces are like those in programs, with one additional option. 

Declaration :: = IdLlst : Access ReadOnlyOption EntryOption 

TypeSpecif ication Initialization ; | ... 

ReadOnlyOption ::= empty | readonly 

The READONLY option can be attached to a variable only in an interface. If this option is specified, 
importers can read the variable but not update it; otherwise, importers are able to read and update 
the variable freely. Note that a readonly variable is not necessarily constant; it can be changed 
from within the program module exporting the variable. Consider the following example: 

Defs: DEFINITIONS = 
BEGIN 

varl: T\ 

var2: readonly T; 

END. 

hripl: PROGRAM EXPORTS Defs = 
BEGIN 

varl: PUBLIC T\ 

var2: public T; 

varl <- el', ... var2 *- e2\ 

END. 

User: program imports Defs = 

BEGIN 

Defs.varl ^ e3\ 

IF Defs.var2 = e4 then . . . 

END. 

In this example, the exporter {ImpI) provides storage for the variables varl and var2. Within Impl 
both are ordinary variables, e.g., var2 can be updated. By importing Defs, the client {User) %dm.s> 
access to the storage for varl and var2 but cannot update var2. Although Defs.varl and Defs.var2 
are referenced indirectly, through pointers in User initialized by the binder or loader, those pointers 
are invisible to the importer and are always automatically dereferenced. 

An interface variable must be declared with the attribute public in the exporter. It must not be 
declared with fixed (*' = ") initialization. Assignment ("♦-") initialization is permissible; note, 
however, that such initialization is not performed until the exporting module is started, and 
reference to an interface variable does not cause a start trap in the exporter (see section 7.8.3). 
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A fine point: If an interface component has a PROCEDURE. SIGNAL. ERROR or PROGRAM type, any 
importer expects that component to contain an actual value (e.g.. a procedure descriptor), not a pointer to such 
a value. Thus an interface variable cannot ha\e one of these types. For example, if the declaration 

Proc: PROCEDURE [...]: 
appears in a DEFINITIONS module Dcfs. the declaration 

Proc: PUBLIC PROCEDURE [...] = BEGIN ... END' 
is valid in an exporter of Dcfs: the declaration 

Aw.' PUBLIC PROCEDURE [...] <- SomeProcedure\ 
is not. (In the latter case, a variable containing a pointer to Proc could be exported.) 

In addition to providing common access to data structures, interface variables make default fields 
(section 7.3.2) and inline procedures (section 7.3.3) more useful in definitions modules; that is, 
interface variables can be used within these definitions to access nonconstant information in the 
exporter. Interface variables used for this purpose must be public in the exporter but can be 
declared with the attribute private in the definitions module. This convention is strongly 
recommended to prevent unintended direct sharing of the variables by clients of the interface. Note 
that code within an interface cannot update a readonly component of that interface. 

We will see in section 7.4.2 another means of accessing the variables of another program module, 
that of an implicit pointer to frame[...], whose value is initialized by the loader. This offers an 
alternative to interface variables, but leads to compilation dependencies such as those described in 
section 7.2.4. In choosing between the two methods, note the following: 

Each imported interface variable introduces a separate pointer in die link area of the 
importer (see Section 7.7, page 125). On the other hand, each access to such a variable 
generally requires less code and is faster than an access to a field of an imported frame. 

The use of interface variables introduces less severe compilation dependencies; 
recompilation of die exporter does not require recompilation of all importers. 

Compromise positions are also possible. Information to be shared can be grouped into a smaller 
number of variables with record or array types, and those variables can be exported. This reduces 
die number of pointers but increases the amount of (potentially changing) structure in die interface. 

73.2. Default fields in interfaces 

One valuable use of interface variables is in default values for procedure argument records (section 
5.1). Default arguments can contain references to procedures (inline or otherwise), signals and 
interface variables that are components of the same interface. These references are bound to values 
in the same instance of the imported interface as the one supplying the procedure definition itself 
References to non-constant components of other interfaces require that those interfaces be imported 
by the definitions module and all its users (see section 7.4.4). For example, an interface could 
contain: 

globalO: private Queue: - an interface variable 
Add: procedure [/; Item, q: Queue <- globalQ]; 

This declaration allow users to Add items to globalQ, but not to access the variable directiy. Thus 
the statement 

Defs\.Add[myIten^\ 
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is equivalent to 

Defsl .Add [mylleni Defsl .globalQ] ; 

A fine point: 

If a program imports two instances of Defsl. sa\ Dl and D2. the defaulied value for q will be from the same 
instance as the called procedure. In other words. 

I)\.Add[myIicm] is equivalent to D\.Add[m\Item Dl.globalQl ^ 

Dl.Add[m\ltcm] is equivalent to Dl.Add[myltem, Dl.globalQ]. 

In a program module, default arguments of exported procedures (and signals, etc.) require special 
attention. Because of the assignment rule, the DefaultOptions specified in the exporter and in the 
interface are not required to agree. If the implementer and the clients are to behave identically with 
respect to defaults, the same DefaultSpeclfication must appear twice. 

For example, if the interface has the declaration 

Proc: PROCEDURE [x: T ^ el]: 
and the exporter has the declaration 

Proc: PUBLIC PROCEDURE [x: T <- e2] = BEGIN ... end; 

then within the exporter, Proc[] means Proc[e2]: within an importer of the interface, Proc [] means 
Proc [el]. The langauge requires only that the types of el and e2 be compatible with 7; if they 
should also provide the same value, the programmer must ensure this. 

7.3 J. Inline procedures in interfaces 

An inline procedure can be declared within a definitions module. Any caller of that procedure 
must import an instance of the corresponding interface. 

Within a definitions module, the body of an inline procedure can contain references to procedures 
(inline or otherwise), signals and interface variables that are components of the same interface. 
These references are bound to values in the same instance of the imported interface as the one 
supplying the inline procedure itself. References to non-constant components of other interfaces 
require that those interfaces be imported by the definitions module and all its users (see section 
7.4.4). 

Interface components with the attribute private are visible to the bodies of inline procedures 
declared within the same definitions module. An inline procedure referencing such components 
can be imported into a program module in which those components are not visible. Interface 
components used only as free variables or default arguments of imported procedures should not be 
mentioned in the corresponding using clauses. For example, suppose that an interface contains the 
following declarations: 

D omainFautt: S\0\^kL\ 

Proc; PROCEDURE [cardinal] RETURNS [7]; 

N: cardinal = 100; 

Table: private array [0 . . A^) of pointer to T\ 
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//Vor; PROCEDURE [/.-cardinal] RETURNS [T] =: INLINE 
BEGIN 

IF / '-IN [0 . . A' ) THEN ERROR DomainFaulK 

RETURN [if r^Wf']/] = NIL THEN Proc [/] ELSE T(7Z?/^[/]t] 

end; 

Note that the body of an inline procedure (IProc) can contain references to constants (.V), interface 
procedures (Pwc), signals (DomainFault) and interface variables (Ta/j/^) in the same interface. If 
Defsl is an instance of this interface, DefsIJProc references DefslJable, calls DefsLProc, etc. An 
importer cannot reference TaW^ directly because of the private attribute but can reference it 
indirectly through IProc. 

It is not legal for a program module ProgI to call an inline procedure defined in some other 
PROGRAM module Progl. even if Progl imports a pointer to VP.^UE[Prog2]. 

7.3,4 Usage hints for inline procedures in interfaces * 

Expansion of inline procedures can cause internal data stnictures of the compiler to grow rapidly; 
indiscriminate use of the inline attribute can substantially degrade compiler performance or cause 
tables to overflov^. The current compiler has been organized so that inline expansion is particularly 
efficient, and incurs little added overhead, in the following circumstances: 

The inline procedure, with an arbitrarily complex body, is defined within a program 
module and called exactly once in that same module. (Thus introducing named procedures 
for clarifying and structuring a program can be cheap when such procedures are called only 
once.) 

The inline procedure, defined either in a definitions module or a program module and 
called an arbitrary number of times, is very simple, with no local variables, no named 
output parameters, and no side effects. 

The debugger cannot set breakpoints within, or display the expanded source text of, an inline 
procedure (although it can display the local variables resulting from the expansion). Debugging can 
be easier if the inline attribute is used only as needed and is specified after initial testing has been 
successfiilly completed. 



7.4. PROGRAM modulesMMPORTS and exports 

A PROGRAM module may contain 

definitions of constants and types (just like a definitions module), 

declarations of variables, 

actual procedures and signals (chapter 8), and 

^executable statements of its own (i.e., not part of procedure bodies within it). 

At run time, a loaded module (also called an instance of the module — sec. 7.6.3) has a frame which 
provides storage for its declared variables and for connections to other modules' procedures and 
signals. 
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lliese connections are called interface records, and there is one for each interface imported by the 
module. I'he Mesa binding process fills in these interface records with procedure descriptors, signal 
codes, and pointers to program frames and exported \ariables in other modules. 

7.4,1. IMPORTS, interface types, and interface records 

rhe IMPORTS list for a program declares which interface records the program needs and associates 
tliem with definitions modules (ccdled interface types). Interface records and interface types are 
different] A program may only access non-interface elements using an interface type, but can access 
all elements (both interface and non-interface) when using an interface record. 

ITie names of interface records are declared in a program module's imports list. The identifier 
preceding a ":" in the list names an interface record, while tlie name following that same ":'* must 
name an interface type, hi the following example, names ending m\h Rec specify interface records, 
and names ending in Defs specify interface types: 

DIRECTORY Defsl: FROM "defsl", Defs2: from "defs2'*; 

Prog\ PROGRAM imports IRec: DefsL URec: Defsl = 

BEGIN . . . END. 

Within the body of Prog., references like DefsLx are only valid if x is a non-interface element of 
Defsl. However, IRec.x can refer to any element x of Defsl, whether interface or non-interface. 
This distinction is necessary because a call on a procedure, proc, defined in Defsf must refer to the 
actual descriptor in the interface record IRec at run time, not just to its compile-time definition. 

Omitting the name of an interface record in an imports list and giving only the name of an 
interface type means that the record's name should be the same as the type's. For example, writing 

Prog: PROGRAM IMPORTS IRec: Defsl, Defs2 = . . . 

is the same as writing 

Prog: PROGRAM imports IRec: Defsl, Defsl: Defsl = . . . 

Then, within the body of Prog, Defsl refers to an interface record. In fact it is impossible thereafter 
to refer to the interface type Defsl, although one can still refer to the interface type Defsl because 
its name has not been reused. 

Sometimes one needs to have access to more than one instance of an interface record at am time. 
For example, the Mesa compiler needs to access one instance of a symbol table package for the 
program that it is compiling, and at least one for the symbol tables for modules included by that 
program. This can be done by defining a number of interface records for a single interface type, as 
in the following: 

DIRECTORY SymDefs: from "SymDefs"; 

PartOfCompiler: PROGRAM IMPORTS mainSym: SymDefs, auxSym: SymDefs = 

BEGIN... END. 

Within the body of PartOfCompiler, one would access an interface element of SymDefs named 
LookUp for the main symbol table as mainSyniLookUp, and for the auxiliary symbol table as 
auxSym.LookUp. 
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7.4.2, Importing program modules 

Any module can include a program module X by naming X m its directory. One can use X to 
declare program variables of type pointer to frame[J]. frame[.Y'] is not a valid type because 
frames cannot be embedded in other structures. One may obtain a value for pointer to frame[J] 
is from a system procedure as described in the Afesa System Documetilatioti or by iMPORTing. 

A module can import a program X by naming it in its imports list. For example, 
DIRECTORY XProgI: FROM "XProgl", XProg2: from "XProg2"; 

Prog: PROGRAM imports fiwnel: XProgl XProg2 = 
begin . . . END. 

This has an effect similar to declaring 

framel: pointer to fRkUE[XProgl] = . . . ; 
XProg2: pointer to FRAME[JrProg2] = . . . ; 

except that these constant frame pointers will be filled by the Mesa binder. (However, the 
declaration for XProg2 could not actually be written as a valid Mesa statement because of the 
ambiguity inherent in the two occurrences of XProg2 in it.) 

Such imported program constants are the analogs of interface records. More can be done with them 
than with program types (just as one can access more with an interface record than with an interface 
type). In particular, one can access variables and procedures with a frame pointer (as well as the 
compile-time constants to which a program type provides access). Also, one can execute the module 
instance corresponding to a frame pointer using start and restart (sec. 7.8.2) and create additional 
instances of it using new (sec. 7.8.1). 

Accessing values in a program frame as described above treats the frame as a record with its 
variables and its procedures as its components. The price paid for such close coupling with a 
program is that the importer must be recompiled whenever tlie program is. 

7.4.3, Exporting interfaces and program modules 

A module can export an interface if it provides public procedures, signals, errors, or variables whose 
names and types match those of interface elements in a definitions module. In addition, the 
program can export itself as part of an interface if its name appears there with an appropriate 
PROGRAM type. In all these cases, the compiler checks that the type of each exported element is 
assignment compatible (sec. 2.3) with the type of the corresponding interface element. 

A single program module need not provide implementations for all the items in an interface. This 
allows two or more modules to cooperate in completely defining an interface. In such a case, it is 
common for each of the cooperating modules to use interfaces elements provided by the others. It 
can do so by importing and exporting the same interface. 

7.4.4, IMPORTS in DEFINITIONS modules * 

Recall from section 7.2" that a definitions module can contain an ImportsList. One interface, say 
Defs2, must import another, Defsl, if Defs2 requires access to a nonconstant component of the latter, 
e.g., to a procedure (inline or otherwise) or interface variable in Defsl. All interfaces mentioned in 
the InrkportsList of a definitions module must be unnamed. Any importer of Defs2 must also 
import an unnamed instance of Defsl \ in establishing the final binding, all unnamed instances are 
matched. For example: 
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Defs2: definitions imports Defsl - 

BEGIN 

Proc2: PROCEDURE [...] = inline 

begin 

... IF Defsl. mr # v then Defsl. Pwc{. . .]: ... 

end: 

END. 

Prog: PROGRAM IMPORTS DefsK Defsl, AnotherDefsl: Defsl = 

BEGIN 

Defs2.Proc2[...]\ -- expansion references Defsl. Proc, not AnotherDefsl. Proc 

END. 

Note that Prog must import an instance of Defsl, even if it makes no other mention of it, and one 
instance of Defsl must be unnamed. 



7.5. Controlling module interfaces: PUBLIC and PRIVATE 

Every name defined in a module possesses an Access attribute, either public or private (the 
module in which a name is defined is called its home module). These are used to determine whether 
a name may be referenced when its home module is included by some other module. A public 
name can always be used: a private name cannot generally be used, except by modules which 
specify that they share the included (program or definitions) module. The former modules are 
called non-privileged modules, and the latter are called privileged modules. A variable's home module 
is, of course, privileged 

Generally speaking, an Access may be specified 

(a) anywhere a name can be declared. This includes normal declarations, named field lists (for 
records or parameter lists), preceding select in a record's variant part, and the declaration 
for an actual tag in a variant part. 

(b) preceding the TypeSpecification in a type definition. 

In addition, an Access may be specified 

(c) at the beginning of a module (the GlobalAccess), to provide a default Access for any 
identifier in that module when one is not given explicitly for the identifier. 

The syntax in the following section is intended to supersede earlier definitions of the same constructs 
only by showing where attributes may be inserted. Otherwise, the earlier versions are correct. Each 
syntax definition is followed by examples of its use. 

7.5.1. Access attributes in declarations 

The following three subsections deal with the placement of Access options in declarations, field lists, 
and in variant records. 
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7,5.1.1 , Declared names 

llie form of Declaration specifying an Access for its declared names is as follows: 
Declaration :: = IdList : Access TypeSpecification Initialization ; 

Hxamplcs: 

qL q2\ PUBLIC INTEGER <- 0; 

Mine: private type = {yes, no, maybe}: 

Mine can only be used in (i.e., seen from) privileged modules. To non-priviliged modules it is not 
visible at all. 

7:5.1.2. Names specified infield lists 

The forms for specifying Access in a NamedFieldList (sec. 3.4.1) are as follows: 

NamedFieldList :: = 

IdList : Access FieldDescription I 
NamedFieldList JdList : Access FieldDescription 



FieldDescription 



TypeSpecification | 
TypeSpecification <- Expression 



Example: 

6/^: PUBLIC record 

[ 

^: integer, 

b: PRIVATE INTEGER ♦■ 1234, 

C d: BOOLEAN, 

^: PRIVATE BOOLEAN 

]: 

A non-privileged module could only access components a, c. and d in this case, and then only using 
qualified references such as blk.a. Within a non-privileged module, extractors and constructors 
cannot be employed for a record type with any private components. 

7.5. 1.3. Names for variant parts and for tags in variant records 

The forms for specifying Access in a Va riant FieldList or Tag (sec. 6.3.1) are as follows: 

VariantFieldList :: = 

CommonPart identifier : Access VariantPart I 
VariantPart | 
NamedFieldList | 
UnnamedFieldList 

CommonPart ::= empty | 

NamedFieldList, 



VariantPart 


::= SELECT Tag FROM 




VariantList - same; 




ENDCASE 


Tag 


::= identifier : Access TagType 




COMPUTED TagType 


TagType 


:: = TypeSpecification | * 
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Example: 

VarRec: public type = record 

[ 

link: pointer to VarRec. -■ public common component 

vpl: SELECT igl: PRIVATE luype FROM -- pubUc variant, private tag 
adji => 

[ 

you Get: This It em 

iGet: private select tg2: * from - a private variant part 

ENDCASE 

] 

ENDCASE 

]; 

Suppose a non-privileged module has a record of type VarRec. Then it could access variant part vpl 
but neither tag tgl nor variant part iGet. This only prevents it from referring to tgl by qualification; 
it may still use a discriminating select (which implicitly accesses tgl) for records of type VarRec. 
Thus, an adjl arm of such a with. . .select could access component youGet. Hov^ever, it would be 
unable to access component iGet in any case. 

Notice that the only wav that the tag of a variant can be changed is by writing a variant constructor 
(sec. 6.3.3). 

7J.2 Access attributes in TYPE definitions 

The form for specifying a Typeldentif ier whose defined type has an explicit Access is as follows: 
Declaration :: = ... | IdList .type = Access TypeSpecification ; 

Example: 

OurType: public type = private RECORD[compl: integer, comp2: boolean]; 

A non-privileged module could declare records of type OurType, but it could not access the record 
components. The module could, however, pass values of type OurType as parameters, receive them 
as results from procedures, and use them as operands of a fundamental operation (♦-, =, #). 

The Access in this form could be specified as public, but this would be pointless (if OurType is 
PUBLIC then its type would be public by default; if OurType is private then its type attribute is 
irrelevant). Note: Only na?nes specified within the defined type are affected by this form of 
attribute specification. Consequently, it is intended for use only when defining record types and is 
just a factorization: the private could have been written after each inner colon; also, specific fields 
can be made accessible by writing public internally, as shown below: 

AlmostPrivateType: public type = private record 

[ 

com/?/: PUBLIC integer, -- overrides outer private 

comp2: boolean 

1; 
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7.5 J. Default global access 

If, as in section 7.4.1, a declaration specifies an Access for a name, then that unilaterally 
determines its Access. If not, the given item receives a default Access. The default may be 
specified by the programmer in the GlobalAccess for a module: otherwise one is assumed (for a 
program module, the normal default is private, for a definitions module, it is public). For 
example, 

A//: PROGRAM = PUBLIC - Specified GlobalAccess 

BEGIN 
END, 

M3\ PROGRAM = - PRIVATE (by default) 

BEGIN 
END. 

7,5.4, Accessing thePRWkJE predefined symbols of other modules* 

A module may be privileged to use private items in an included module by using a Shares clause: 
this contains a list of the (included) module names whose private symbols it needs to access. 
Consider the Friendly module below: 

DIRECTORY 

SpecialDefs: from "specialdefs", 
StandardDefs: from "standarddefs", 
/^r/va/eZ)e/5: FROM "private"; 

Friendly: PROGRAM SHARES PrivateDefs. SpecialDefs = 

BEGIN 
END. 

In this case. Friendly cslu use private symbols defined by PrivateDefs and SpecialDefs but not the 
PRIVATE symbols of StandardDefs. There is no particular significance to the ordering of module 
names listed after shares. Any kind of module may use shares (but it ought to be one that is 
"friendly", to say the least). 

7.6. The Mesa configuration language, an introductory example 

This section discusses C/Mesa, the Mesa configuration language, first by example, and then more 
rigorously by syntactic definition and detailed semantics. It ends with a number of detailed 
examples which explore some of the more intricate parts of C/Mesa. 

We first present an example consisting of three Mesa modules: 
An interface (a definitions module), 
an implementor for it (a program module), 
and a client for the implementation (also a program module). 

The example is presented here to show the relationships among definitions, implementors, and 
chents. Following it will be a sequence of example configurations for systems constaicted from this 
implementor and client. The line numbers in the left margin are provided for ease of reference and 
are not part of the source code. First the interface: 
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dl 
d2 
d3 
d4 
d5 
d6 



Lexicon Defs: definitions = 

BEGIN 

Finds tring: procedure [string] returns [boolean]: 
AddString: procedure [string]; 
PrintLexicon: procedure; 

END. 



7,6.1. Lexicon: a f nodule implement ingLcxkonDcfs 

llie following module (Lexicon) implements the LexiconDefs interface. That is, 

(a) Lexicon declares public procedures FindString, AddString., and PrinlLexicon, which have 
procedure types conforming to their counterparts in the definitions module; 

(b) Lexicon EXPORTS the interface LexiconDefs. 

Lexicon imports three interfaces: SystemDefs. lODefs, and StringDefs. The using clauses of .the 
DIRECTORY notc which procedures are defined in each. 

Details on these and other Mesa system interfaces are contained in the Mesa System Documentation. 

The code for Lexicon follows. For reading convenience, any references to procedures from imported 
interfaces are in boldface. 

il: DIRECTORY 

i2: IODefs:¥ROU"\odth"usmQ[WriteLine\ 

i3: Iex/coA?Z)^ji: FROM "lexicondefs", 

i4: StringDefs'. FROM "stringdefs" using [Appends trin^, 

i5: SystemDefs: from "systemdefs*' using [AIlocateHeapNode, AllocateHeapString]\ 

i6: 

i7: Lejc/coA?: PROGRAM 

i8: MPORTS SystemDefs. lODefs, StringDefs 

i9: EXPORTS LexiconDefs = 

ilO 

ill 

il2 

il3 

il4 

il5 

il6 

il7 

il8 

il9 

i20 

121 

122 

123 

124 

125 

i26 

127 

128 

129 

130 

131 

132 

133 



begin 

Node: type = record [Ilink rlink: NodePtK string: string]; 

NodePtr: type = pointer to Node: 

Comparative: type = {lessThan, equalTo. greaterThan}\ 

root: NodePtr ^ nil; 

Finds trifjg: public PROCEDURE [s: string] returns [boolean] 
begin return [5"e^rc/zFor5'm>zg[roo/, 5]]; end; 

SearchForString: PROCEDURE [n: NodePtr, s: STRING] 
RETURNS [found: BOOLEAN] = 
BEGIN 
IF n = NIL THEN RETURN [FALSE]; 

SELECT LexicaICompare[s, n. string] from 

lessThan => found ^ SearchForString[n.IIink s]: 

equalTo => found <- true; 

greaterThan => found ^ SearchForString[n.rIink s]; 

endcase; 
RETURt^ [found\: 
end; 
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i34: /Wf^^.V/r/V/g: PUBLIC PROCEDURE [5; STRING] = 

135: BEG\N Inser!Strnig[rooL s]: end: 

136: 

137: Inserts ning: procedure [/7; NodePir, s: string] = 

138: begin 

139: NewNode: procedure returns [//; NodePtr\ = 

140: BEGIN OPEH SystemDefs: 

141: n ^ AllocateHeapNode[s\ZE[Node]]: 

142: /7t ♦- Node[sning: AllocateHeapStnng[s.Jengih\ Ilink: nil, rlink: nil]: 

143: StrmgDefs,AppendString[n,strmg s]: 

144: return; 

145: end; 

146: 

147: IF n = nil then root ^ NewNode [ } -- then just return 

148: else 

149: SELECT LexicaICompare[s, n,string] from 

150: lessThan => if nJlink # nil then InsertStrmg[nJlmk s] 

151: ELSE nJIink *- NewNode[]\ 

152: equalTo => null; - already there; just return 

153: greaterThan => \E tirlink # H\L then Inserts tring[n.rlink, s] 

154: ELSE n.rlink *- NewNode[]\ 

i55: endcase; 

156: end; 

157: 

158: LexicalCompare: procedure [si, s2: string] returns [c: Comparative] = 

159: BEGIN 

160: n: cardinal = min [slJengtk s2Jength]\ 

161: /: cardinal; 

162: for / IN [O../1) DO 

163: SELECT LowerCa5e[5l[/]] from 

164: <LowerCase [52 [/]] = > return [lessThan]: 

165: >LowerCase[s2[i]] => returh [greaterThan]: 

166: endcase; 

167: ENDLOOP; 

168: C*- SELECT 5l./e/2g/A FROM 

169: <s2Jength => lessThan, - si Is shorter than s2 

170: >s2Jength = > greaterThan, -- si Is longer than s2 

171: ENDCASE => equalTo: -- lengths are the same 

172: return[c]; 

173: end; 

174: 

175: lower, packed array character^ A .. 'Z] of character = 

176: f a/b/c/d;e,T/g,'h/l/j,''k/l/m,'n, 0, p,'q/r/s,'t/u,'v,'w,'x/y/z]; 

177: 

178: LowerCase: procedure [c: character] returns [character] = 

179: BEGIN return [if c IN ["A./Z] then /aH'er[c] else c]; end; 

180: 

181: Pn/2/Lex/co/z: PUBLIC PROCEDURE = 

182: BEOm PrintNode[root] end: 

183: 

184: PrintNode: PROCEDURE[n; NodePtt] = 

185: BEGIN 

186: IF /? = NIL THEN RETURN; 

187: PrintNode[nMink]: 

188: IODefs,WriteLine[n.strmg]: 

189: PrinlNode[n,rlink]: 

190: end; 

191: END. 
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7.6.2. l-CxiconClicnt: a client module 



'llie module, I.exiconClieni, below is a client for Lexicon and IMPORTS LexiconDefs. It is also a 
client for tlie interface lODefs (and also uses the constant CR defined in lODefs in section 7.1). 
'Hie program provides a simple terminal interface to a user for testing Lexicon. 

Cl: DIRECTORY 

c2: lODefs: from "iodefs" using [CR, ReadChar, ReadLine, WriteChar, WhleLine]. 

c3: LexiconDefs: from "lexicondcfs" using [AddSlring. FindSlring. PrintLexicon]: 

c4: 

c5: LexiconClieni: PROGRAM imports lODefs, LexiconDefs = 
c6: 

c7: BEGIN OPEN lODefs, LexiconDefs; 

c8: 

c9: s: string *■ [80]; 

ch: character; 

DO -- loop until stopped by user typing q or Q (last case below). 
, WriteChar{CR\, W'nreZ,ine["Lexicon Command: "]; 
ch <- ReadCharU: 
WriteChar[ch];-- Echo the character (ReadChar doesn't). 

SELECT cA FROM 
'f,T=> 
BEGIN 

WriteLine[" ind: "]; -- terminal will read: "find: " 

ReadLine [s]\ -- s will contain the string read from the terminal 

\F FindString[s] THEH WriteLine[" ■- found"] 

ELSE WriteLine [" -- not found"]; 

end; 
'a, 'A => 

begin 

WritelAne^' dd\ "]; -- terminal will read: "add: " 

ReadLine{s\, 

AddString[s]; 

end; 
'p/P=> 

BEGIN 

WriteLine["nnl lexicon"]; -- terminal will read: "print lexicon" 

WriteChar[CR]\ PrintLexicon[]; 
end; 
*q.'Q=> 
BEGIN 

WriteLine [" uit"]\ WriteChar[CR]\ -- terminal will read: "quit" 
stop; 
end; 
ENDCASE =>WriteLine[" Commands are Find, Add, Print lexicon, and Quit"]; 

ENDLOOP; 



clO 
ell 
cl2 
cl3 
cl4 
cl5 
cl6 
cl7 
clS 
cl9 
c20 
c21 
c22 
c23 
c24 
c25 
c26 
c27: 
c28 
c29 
c30 
c31 
c32 
c33 
c34 
c35 
c36 
c37 
c38 
c39 
c40 
c41 
c42 



END. 



7.6.3. Binding, loading, and running a configuration: an overview 

A configuration description, a "program" written in C/Mesa, describes how a set of Mesa modules 
are to be bound together to form a configuration. This binding is accomplished by "compiling" the 
configuration description (or, configuration for short) and results in a binary configuration description 
(a BCD). 
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The simplest (or atomic) BCD is the object module for a Mesa program module. Thus, the Mesa 
compiler produces the simplest BCDs, and the C/Mesa compiler (also called the Mesa Binder) 
produces complex BCDs from simpler ones. Indeed, a configuration may combine both atomic and 
non-atomic BCDs together into a single, new BCD. For these reasons, the object modules produced 
by the Mesa compiler have the same form of names as the output of the Binder, i.e., names of the 
form "BasicName.bcd". 

Once a BCD has been created, it can be loaded and run. 

Loading is a sequence of two actions. The first makes an instance of tlie configuration by allocating 
a frame for each atomic module in the BCD. Each frame has space for the module's static variables 
(those declared in the main body of the module) and some extra space for information used by the 
Mesa system. Imported procedures and variables are accessed via links. Space for these links is 
allocated either in the frame or in the code of the module. 

The second part of loading completes the binding process by filling in the links for each module 
instance in the configuration instance. Some of these links will "point to" procedures and variables 
in the same configuration. Others will "point to" procedures and variables in the running system in 
which the configuration is being loaded. 

Once a configuration is loaded, each module instance in it has all its interfaces bound. However, no 
code has been executed in the instances, so global variables are not initialized, and no mainline 
statements have executed. STARTing (sec. 7.8.2) an instance executes any code for initializing static 
variables and also executes its mainline code. For correct operation, this must occur before any of 
its procedures are used or before any of its global variables are referenced. If a module is not 
explicitly STARTed before one of its procedures is called, then a trap occurs, and it is automatically 
started. Once it stops (sec. 7.8.2), the procedure call is allowed to proceed. Subsequent procedure 
calls will not repeat this trap and auto-initialization sequence. Section 7.8 details how these 
mechanisms generalize for configurations. 

7.6.4, A configuration description forrunningLexiconClitni 

The following configuration will bind Lexicon, LexiconClienU and other necessary modules and can 
be used to start the client program running. The comments to the right of each module name 
indicate which interfaces are imported and exported by that particular module; they are not part of 
Configl. This configuration is completely self-contained: all the needed imports are satisfied by 
interfaces exported from modules which are part of the configuration. 

Configl'. CONFIGURATION 

CONTROL LexiconClient = 

BEGIN 

Fsp\ — EXPOKXS SystemDefs 

lOPkg; - EXPORTS /OZ)e/s 

Strings: - EXPORTS StringDefs 

Lexicon: - mports SystemDefs, lODefs, StringDefs exports LexiconDefs 

LexiconClient; - imports lODefs, LexiconDefs 
end; 

To see that this configuration is completely self-contained, notice that LexiconClient imports lODefs, 
which is exported by lOPkg, and imports LexiconDefs, which is exported by the instance of 
Lexicon. Similarly, the other instances' import requirements are satisfied by some exported interface 
in ConfigL 
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7.7 C/Mcsa: svntax and semantics 



ITie following is the complete syntax for C/Mesa. It bears strong resemblance to Mesa itself, but 
tliis grammar describes a completely separate language. A phrase class beginning with a C indicates 
a syntactic unit that is unique to C/Mesa. All the other units have the same syntax (but not 
necessarily exactly the same semantics) as they do in Mesa itself. 

ConfigDescription :: = CDirectory -optional 

CPacking 
Configu ration . - note the final period 

CDirectory ::= -same as in Mesa, only no USING clauses 

Configuration ::= identifier : CHead = 
CBody 

CExports ::= empty | exports ItemList 

CExpression :: = CPrimary | CExpression then CRightSide 

CLeftSide ::= Item |[ ItemList ] 

CBody :: = begin CStatementSeries end 

CHead :: = configuration CLinks Imports CExports ControlClause 

ControlClause :: = control identifier | empty 

CLinks :: = empty | links : code | links : frame 

CPacking ::= empty | CPackSeries ; 

CPackList :: = pack IdList 

CPackSeries ::= CPackList | CPackSeries ; CPackList 

CPrimary ::= CRightSide | CPrimary plus CRightSide 

CRightSide :: = Item | Item [ ] CLinks | Item [ IdList ] CLinks 

CStatement :: = CLeftSide *- CExpression | 
CRightSide! 
Configuration 

CStatementSeries ::= CStatement | 

CStatementSeries ; | 
CStatementSeries ; CStatement 

Imports :: = empty | imports ItemList 

Item ::= identifier | identifier : identifier 

ItemList :: = Item | ItemList , Item 

We will use the term "component" to refer to the parts of a configuration; i.e., for both atomic 
modules and configurations containing several modules. When necessary, the kind of component 
will be expressly given. 

Similarly, we will use the term "interface" to stand for an interface record or a module instance (if 
used in discussing imports or exports), and we will distinguish as necessary. However, "interface" 
will never include or imply the term "interface type" (sec. 7.4.1). 

Lastly, we will need to distinguish between instances of components and their prototypes (the BCD 
files) from which such instances are made. Hence, a program prototype is the BCD file for a Mesa 
program module, and a configuration prototype is the analog for configurations. If the term 
prototype is used by itself, it includes both cases. 

The CPacking and CLinks clauses in the syntax are directives to the Mesa Binder. CPacking 
identifies modules whose code should be packed together for swapping purposes. CLinks specifies 
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for a module or a configuration whether links to imported interfaces should be stored in the frame 
or in the code. I'he use and implications of these optional clauses is described in Appendix D. 

1,7.1, IMPORTS, EXPORTS, and DIRECTORY /// G/Mcsa 

For completely self-contained, simple configurations like ConfigL a configuration description is 
primarily just a list of component names. An instance of each named component will be part of the 
configuration, and if a component imports any interfaces, they will be supplied by those exported 
from other components of the configuration. 

Configurations need not be self-contained, however, and may themselves import interfaces to be 
furtlier imported by their components. In this way, subsystems can be constructed with some 
imported interfaces unbound. Loading such a configuration or naming it as a component in another 
configuration will supply the necessary interfaces. Furthermore, a configuration can piake exported 
interfaces available for importation by other modules and configurations. For example, the 
interfaces SystemDefs, lODefs, and StringDefs needed by Configl would normally be supplied by a 
pre-existing Mesa system configuration. Therefore, it is really not necessary to include instances of 
Fsp, lOPkg, and Strings in ConfigL Instead, it can just import them: 



c2.1 
c2.2: 
c2.3 
c2.4 
c2.5 
c2.6 
c2.7: 



Configl: CONFIGURATION 

IMPORTS SystemDefs, lODefs, StringDefs 
CONTROL LexiconCUent = 

BEGIN 

Lexicons 

LexiconCUent', 

END 



The imports clause in a configuration serves the same purpose as in a program module. The rule 
for importing is: If some component named in a configuration imports SomeDefs, and SomeDefs is 
not exported by a component in the configuration, then it must be imported. For example, 
SystemDefs did not have to be imported into ConfigL but it did have to be imported into Configl, 

The rule for exports is simpler: If a component in a configuration exports an interface, that 
interface may also be exported another level from the configuration. It is not required that it be 
exported, however. This important feature enables one to control what is exported from a 
configuration and what is to be hidden from external view. 

None of the example configurations given so far have had a directory section. This is because the 
default association of a component named Prog is to a file named "Prog.bcd" in which the 
ModuleName is also Prog. Since this is often the case, the programmer normally does not need to 
supply one. A directory part would be needed if the file did not have such a defaultable name. 
For example: 

directory 
Prog: FROM "OldProgFile"; 

could not be omitted if the component named Prog is contained in the file "OldProgFile.bcd", 
rather than in "Prog.bcd". 

7.7,1 Explicit naming MPOKTS^andEXPOPJS* 

In Mesa, names may be given to the interface records in an imports list (sec. 7.4.1); the same is true 
in a configuration description. These names can then be used to supply the interfaces needed by 
component instances in the configuration. The notation for explicitly supplying interfaces to a 
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component is similar to that for parameter lists in Mesa (except tliat there is no keyword notation for 
explicit imports parameter lists). For example, lines c2.1 through c2.5 above could have been written 
as 



c2a.l 
c2a.2 
c2a.3 
c2a.4 
c2a.5 



Config2A: configuration 

IMPORTS alloc: SystemDefs. io: lODefs, sir: StringDefs 
CONTROL LexiconCliefU = 

BEGIN 

Lexicon[alIoc io. str]: 



ITie interfaces listed after Lexicon must correspond in order and (interface) type with tlie imports 
list for Lexicon (look at Lexicon in sec. 7.6.1 to check this). 

A^name may also be given to each component instance in a configuration by preceding the instance 
with "identifier :". This facility is necessary to distinguish multiple instances of the same 
prototype from one another. For example, we could name the Lexicon instance in line c2a.5 as 
follows: 

alex: Lexicon [alloc, io, sir]: 

Lexicon exports an interface whose type is LexiconDefs, and that interface record can also be named. 
The following further modification to line c2a.5 names it lexRec: 

lexRec: Lex icon Defs ♦- alex: Lexicon [alloc, io, str\: 

Here, as in Mesa, the type of lexRec follows the colon in the declaration, and lexRec is assigned the 
(single) interface exported by Lexicon. However, the type LexiconDefs is not actually necessary (it is 
inferred from Lexicons exports list), and the line could have been shortened to 

lexRec ^ alex: Lexicon[alloc, io, str]\ 

Using all these explicit naming capabilities, we can now write a new version of die configuration in 
which none of the C/Mesa default naming is used: 



c3.1 
c3.2 
c3.3 
c3.4 
c3.5 
c3.6 
c3.7 



ConfigS: configuration 

IMPORTS alloc: SystemDefs, io: lODefs, str: StringDefs 
CONTROL lexClient = 

BEGIN 

lexRec: LexiconDefs ^ alex: Lexicon [alloc, io, str]: 

lexClient: LexiconClient [io, lexRec]: 

END. 



An exported interface like lexRec need not always be set as die result of including a component 
instance like alex in the configuration. One can also assign interface records to one another as in 
die following two (equivalent) lines: 

anotherLexRec: LexiconDefs ^ lexRec: 
anotherLexRec *■ lexRec: 

The fonn of CRightSide in these two statements only copies lexRec, whereas ones like line c3.5 
above involve a "call" on a component prototype. The result of that "call" is an instance of the 
component, and a set of results, the interface records exported by it. 

7.7.3. Default names for interfaces and instances * 

A component instance that is not explicidy given a name is given a default name equal to the name 
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of the component prototype. Thus, the body of Config2 \s treated as if the programmer had written: 

BEGIN 

Lexicon: Lexicon: 
LexiconCIient: LexiconCIienf: 

END. 

Similarly, an unnamed interface is given a default name equal to the name of its interface type. So, 
another equivalent body for Config2 is 

BEGIN 

LexiconDefs: LexiconDefs *- Lexicon: Lexicon[]: 
LexiconCIienf: LexiconCIient: 

END. 

The empty imports parameter list in "Iex/co/7[]" specifies that a new instance of the prototype 
Lexicon is to be created. If the empty imports list were not there, the binder would interpret the 
appearance of Lexicon (the one after the colon) as the name of an already existing interface (not of 
an already existing module instance). When no assignment is specified, the empty imports 
parameter list is not necessary, as shown in the earlier examples. 

Nomially, omitting an imports parameter list (or, equivalentiy, specifying an empty list) means that 
die binder should use the default-named interfaces needed by that component instance. Thus, we 
could rewrite a completely explicit (and very wordy, but equivalent) version of Configl: 

c2x.l: Config2X: configuration 

c2x.2: IMPORTS SystemDefs: SystemDefs, LODefs: lODefs. StringDefs: StringDefs 

c2x.3: CONTROL LexiconCIient = 

c2x.4: BEGIN 

c2x.5: LexiconDefs: LexiconDefs ♦- Lexicon: Lexicon [SystemDefs, lODefs, StringDefs]: 

c2x.6: LexiconCIient: LexiconCIient[IODefs, LexiconDefs]: 

c2x.7: END. 

Notice that the defaults greatly simplify a configuration, but that they also obscure a great deal of 
machinery concerned with naming things. It is important that the programmer not completely forget 
tliese details. Otherwise one could commit errors by not distinguishing between interface records 
and interface types, or between component instances and prototypes. For instance, this could be a 
problem if there are multiple component instances. Therefore, one is well advised to assign unique 
names to the instances. 

7. 7.4. Multiple exported interfaces from a single component * 

A component can export more than a single interface. Assigning these exported interfaces to 
interface records is done using a Mesa-like extractor (sec. 3.4.5). For example, if we had a program 
module StringsAndIO that exported both StringDefs and lODefs, we could use it in a modified 
Configl as follow^s: 

c4.1: Config4: configuration 

c4.2: IMPORTS alloc: SystemDefs 

c4.3: CONTROL LexiconCIient = 

c4.4: BEGIN 

c4.5: [str: StringDefs, io: lODefs] *- StringsAndIO []: 

c4.6: Lexicon[aIIoc, io, str]: 

c4.7: LexiconCIient [io, LexiconDefs]: 

c4.8: END. 

Line c4.5 assigns the exported interfaces obtained by instantiating StringsAndIO (that is why it has 
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an explicit, although empty imports parameter list following it) and declares their types as well. It 
would be equally correct to write instead 

[sfn io] <- StnngsAnclIO[]: 

In this case the types for io and sir would be inferred from the types of the interface records 
exported by SiringsAndlO. However, if the programmer had written instead, 

[/a stf] ^ StrmgsAndIO[Y 

with the positions of io and str reversed, that would have been accepted, but would have caused 
errors in both lines c4.6 and c4.7 because their inferred types would not match those explicit imports 
parameter lists. Be cautious when doing this. 

Default names could also have been used for the exported interfaces in line c4.5, and Config4 could 
simply have been written as 



c4a.l: 


Conflg4A\ CONFIGURATION 


c4a.2: 


IMPORTS SystemDefs 


c4a.3: 


CONTROL LexiconClient 


c4a.4: 


BEGIN 


c4a.5: 


StringsAndfO; 


c4a.6: 


Lexicon: 


c4a.7: 


LexiconClient\ 


c4a.8: 


END. 



This would assign the exported interfaces to the default-named records StringDefs and lODefs and 
would use diem in the defaulted import parameter lists for Lexicon and LexiconClient, Line c4a.5 
could also show what StringsAndIO exports using the default names for its exported records. This 
would give rise to the statement: 

[StringDefs, lODefs] <r StringsAndIO [I 

Cases like this require that the user be aware of the distinction between interface records and 
interface types: StringDefs names an interface record here, but in line c4.5, it names an interface 
type. 

7. 7,5, Multiple components implementing a single interface * 

An exported interface can be the result of contributions by a number of components. Think of the 
interface as a logical unit that may be implemented by a number of cooperating physical units (i.e., 
modules and configurations). For example, assume that Lexicon is divided into two modules 
LexiconFA and LexiconP. with LexiconFA providing the procedures FindString and AddString, and 
Lexicon? providing PrintLexicon. Each exports LexiconDefs, but neither fully implements that 
interface. Still, LexiconClient will see a single interface in the following: 

c5.1: ConfigS: configuration 

c5.2: IMPORTS SystemDefs, lODefs, StringDefs 

c5.3: CONTROL LexiconClient = 

c5.4: BEGIN 

c5.5: lexRec: LexiconDefs ^ LexiconFA[]: -- use default imports 

c5.6: lexRec ^ LexiconP[]\ - merge interface contributions 

c5.7: LexiconClient[IODefs, lexRec]\ 

c5.8: END. 

The two separate assignments to lexRec above actually merge the interface elements exported by the 
two modules. This merging does not allow any duplication of elements, and if bodi modules 
exported PrintLexicon, for example, an error would be generated during processing of ConfigS by 
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tlie Binder. 

ITie user may control the merging of interfaces himself using the plus operator. To obtain the same 
effect as above (but by explicit specification), one could write 



lexRecFA ^ Lex icon FA [ ]; 
lexRecP ^ LexiconP[]: 
lexRec *- lexRecFA PLUS lexRecP: 
LexiconCIientyODefs. lexRec]\ 



one part 

the other part 

the merge 

same as line c5.7 



If the programmer wanted to use the original Lexicon, but use LexiconFs Prim Lexicon in the 
interface instead of Lexicons, he could use the then operator: 



lexRec *- Lexicon[]: 
lexRecP ^ LexiconP[]\ 
lexRecNew ♦- lexRecPJHEH lexRec: 
LexiconClient [lODefs, lexRecNew]\ 



- defines a complete interface 

- defines one procedure 
-- this order is important 



The THEN operator makes an interface that includes all the elements defined by lexRecP (the left 
operand) together with those from lexRec (the right operand) that do not duplicate any in lexRecP. 
ITiis could be usefial if one simply wanted to test a new version of PrintLexicon procedure without 
altering Lexicon itself during the debugging period. Also, one could use then to provide a number 
of alternative PrintLexicon procedures, with the standard one incorporated in Lexicon. 

7. 7. 6. Nested (local) configurations 

Configurations may be defined within configurations, much like local procedures (sec. 5.7) may be 
defined within other procedures in Mesa. They can then be instantiated and parametrized, and they 
can export interfaces (just like any configuration). 

Nested configurations can be used to hide some of the interfaces exported by components in a 
configuration. For example, suppose that multiple instances of some component ProgMod were 
needed in a configuration, and further suppose that ProgMod exports the interface ProgDefs, Even 
if none of the exported ProgZ)^;^ interface records are needed in the configuration, they would each 
have to be given a unique name to avoid an interface merging error (sec. 7.7.5). 

This could be avoided by defining the following nested configuration: 
NonexportingPM: configuration = begin ProgMod END. 

Using NonexportingPM in place of ProgMod avoids the duplicate interface problem because the 
local configuration does not export the interface ProgDefs produced by instantiating ProgMod within 
it. 



Nested configurations can also be used to avoid writing sequences of C/Mesa statements more than 
once. By collecting such a sequence in a nested configuration, one can get the effect of writing the 
whole sequence simply by instantiating the configuration. 

The scope rules for names in C/Mesa allows a nested configuration to access interfaces and other 
(also nested) configurations outside it. So, one configuration can make instances of others. 
However, in its imports list, a nested configuration must name any interfaces that its components 
import but which are not satisfied within it. That is, interfaces are never automatically imported into 
a nested configuration. 
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7.8. Loading modules and configurations 

ITiis section describes how configurations are loaded and run. Simple, atomic modules are discussed 
first, and then more general configurations. 

Loading and running an atomic module is a sequence of four actions: 

(1) loading its object code (from the .BCD file), 

(2) allocating a frame for its static variables, 

(3) filling in procedure descriptors for imported procedures and frame pointers for imported 
modules, 

(4) initializing the module's variables and executing its mainline code. 

Actions (1), (2), and (3) are acomplished by system procedure, documented in the System 
Documentation. Action (4) can be accomplished by explicitly starting the instance or by means of a 
trap on the first call to any of its procedures (both of these methods are described below^). 

7. 8, L The new operation for making copies of modules 

The syntax for the new operation is 

Expression :: = ... | new Variable 

The Variable may be the name of an imported frame pointer, a pointer to the frame of a program 
module, a program variable, or the module name of the module containing the new statement. For 
example: 

proglnstl, proglnsfl: pointer to frame [?rog]; 

proglnsd ^ new proglnstl; 

The new instance is only a copy of the frame insofar as its interface records are concerned. In all 
other respects it is uninitialized, just like a new instance. In particular, it must be started to supply 
its program parameters (if any) and to initialize its global variables. At the time the copy is made, it 
will have exactly the same bindings as the original. If some of the globally available interface 
records maintained by the loader (sec. 7.8.2) later change, the copy may be bound differently than 
the original. 

If a module imports a program Pimpl (sec. 7.4.2), the operation "new PimpF copies Pimpl 

A program module's type may be declared in a definitions module in the same way as a procedure's 
type is. Such a defined program is part of the interface defined by that definitions module and may, 
therefore, be imported by another module as part of tliat interface. Then, copies of that module can 
be made using the new operation. For example, assume that the following declaration appears in 
the definitions module, Defs\ 

ExportedProg: PROGRAM [/: INTEGER]; 

Any program that imports Defs will then have access to a value named ExportedProg which will 
have been bound (in step (3) of the loading process) to an instance of a program whose parameter 
types conform with those of ExportedProg. The only operation that a program can perform using 
this value is to start it, restart it, or make a copy of it using "new ExportedProg'. In summary, 
a program imported as part of an interface behaves like a value that is a pointer to a frame. 
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If a program, say Prog, wishes to create a copy of itself, it can say: 
copy: POINTER TO FRAME [/Vog]; 
copy *- NEW Prog: 

7A2. How the loader binds interfaces 

Elach instance of an atomic module or of a configuration may export some interfaces. To make 
these exported interfaces available for importation by other instances, the loader maintains a single, 
simple global table of all the exported interfaces. If any duplicates are created as the result of a 
NEW, they are merged into the already existing interface records as if a then (sec. 7.7.5) had been 
done. 

Tlie moral here is that complicated binding to hide interfaces, etc. must be done using the binder, 
and only the simplest, most straightforward forms should be used at loading time. 

7,8 J, START mg, STOPping, and REST ART ing module instances 

The START operation suspends the execution of the program or procedure executing it and transfers 
control to a new, uninitialized instance of an atomic module. Additionally, if the program instance 
being started requires parameters, they are supplied as part of the start. Similarly, if the program 
being started is specified to return results (more details below), then the start operation may appear 
in a RIghtSide context, and the returned value is the value of the operation. Its syntax is 

StartStmt :: = start Call | .. . 

StartExpr :: = start Call | . . . 

The variable following the word start must represent a global frame pointer or program variable; 
i.e., its type must conform to some pointer to frame type or program type. Here are some 
examples of its use: 

start proglnst: 

START ExportedProg[S-^j]\ 

X ♦- START progWithResuIt [first Arg: a, second Arg\ b]\ -keyword parameter list 

When a program is started, it first executes code to initialize any static variables that were declared 
with initialization expressions. The initializations are done in the order in which the variables were 
declared in the program. Also, they may call both local and imported procedures (since descriptors 
for all imported procedures are filled in as part of the new operation - sec. 7.7.1). 

After all initialization expressions are complete, the mainline statements of the program commence 
executing. Control can then return to the caller (the program or procedure which initiated the 
START) in one of two ways: the started program may stop or it may return with results (however, 
it cannot use both). 

A program that executes a stop can be RESTARTed later, restart is distinct from start primarily 
because it cannot pass parameters as start can. If a program does not return results, it either by an 
explicit use of stop or by running off the end of the program. 

If a program declares (in its ModuleHeader) that it returns results, it uses return statements just 
as does a procedure (and it cannot use stop). A return from a program does not deallocate its 
global frame. The syntax for restart and stop is 
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RestartStmt ::= restart Variable | .. . 
StopStmt ::= STOP | . . . 

ITie Variable following restart must be a pointer to the frame for a program instance or a 
program variable, just as for start. A program that returns results or has am off the end cannot 
be RESTARTed. Attempting to do so will result in a am time error. 

A module instance can also be STARTed "automatically". If a call is made on a procedure in an 
instance that has not yet been started, a start trap occurs. If the module does not take parameters 
when started, dien it is started by the Mesa start-trap handler. When it stops or returns, the trap 
handler completes the procedure call that was in progress when the trap occurred. (See the next 
section for fiarther discussion of the start trap for configurations.) 

Warning: A module must be STARTed either explicitly or implicitly before any attempt is made to 
access its variables through a pointer to frame. 

7,8.4, Loading and starting configurations 

By using system routines, one can also make instances of configurations that are more than simple, 
atomic modules. A non-atomic configuration cannot be STARTed (what would it mean to start 
one?), but its control module can (if it has one). Basically, the control module acts as the 
representative for the whole configuration (since a C/Mesa configuration description does not 
contain executable Mesa statements). Thus, a program that starts the control module for a 
configuration has essentially STARTed the configuration. If the order of starting some of the 
instances in a configuration is important or if they take arguments when started, its control module 
should START them explicitly. 

The start trap works for configurations as well as for atomic modules. If a start trap occurs for a 
module M in configuration C with control module cA/, then the trap handler automatically starts cM 
rather than M. If the handler discovers, however, that cM has already been started, it will start M 
(since cM would have started M if it had intended to). In fact, if the handler starts cM but still 
finds M unstarted when cM stops, it will start M itself before finally returning from the trap. Then 
the procedure call that caused the trap will be allowed to go through. 

Fine points: 

If an attempt is made to RESTART a program which has not been started, a START trap will occur and then 
the RESTART will proceed. 

Other forms of START and STOP statements are used to catch signals. This is discussed in Chapter 8, but the 
forms look roughly as follows: 

START somelnstance [ ComponentList ! Catch Phrase ] 
STOP [! Catch Phrase] 
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CHAPTER 8. 



SIGNALLING AND SIGNAL DATA TYPES 



Signals are used to indicate when exceptional conditions arise in the course of execution, and they 
provide an orderly means of dealing with those conditions, at low cost if none are generated (and 
they almost never are). For example, it is common in most languages to write a storage allocator so 
that, if asked for a block whose size is too large, it returns a null (or otherwise invalid) pointer value. 
Any program which calls the allocator then embeds the call in an if statement, and checks the return 
value to make sure that the request was satisfied. What that procedure then does is a very local 
decision. 

In Mesa, one would write the allocator as if it always returned a valid pointer to an allocated block, 
and calls to it would simply assign the returned value to a suitable pointer, without checking whether 
or not the allocation worked. If the caller needs to gain control when the allocator fails, the 
programmer attaches a Catch Phrase to the call; then if the allocator generates the signal 
BIockTooLarge, and the caller has indicated that it wants to catch that signal, it will. 

This way of handling exceptions has two important properties, one for the human reader of the 
program, and one for its execution efficiency: 

Anyone reading a program with a call on the allocator can see immediately that an 
exceptional condition can arise (by the catch phrase on the call or nearby); he then knows 
that this is an unusual event and can read on with the normal program flow: if statements 
do not have this characteristic of distinguishing one branch from the other. 

When the program is executing, the code to check the value returned by the allocator on 
every call is not present and therefore takes no space or execution time. Instead, if a signal 
is generated, there is more overhead to get to the catch phrase than a simple transfer; but 
since it happens infrequently, the overall efficiency is much higher than checking each call 
with an if statement. 

Signals work over many levels of procedure call, and it is possible for a signal to be generated by 
one procedure and be handled by another procedure much higher up in the call chain. We later 
discuss the mechanisms by which this is done; until then, examples show signals being caught by the 
caller of the procedure which generated the signal. 



8.1. Declaring and generating signals and errors 

In its simplest form, a signal is just a name for some exceptional condition. Often, parameters are 
passed along with the signal to help a catch phrase which handles it in determining what went 
wrong. It is also possible to recover from a signal and allow the routine which generated it to 
continue on its merry way. This is done by a catch phrase returning a result; the program which 
generated the signal receives this result as if it had called a normal procedure instead of a signal. 
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lliercfore, from the type viewpoint, signals correspond \ery closely to procedures; in fact, the type 
constmctor for declaring signals is just a variation of the one for procedures: 

SignalTC :: = SignalOrError ParameterList returns ResultList | 

SignalOrError ParameterList | 
SignalOrError returns ResultList | 
SignalOrError 

SignalOrError ::= signal | error 

For example, the signal BlockTooLarge might be defined to carry along with it two parameters, a 
Zone within which the allocator was trying to get a block, and the number of words needed to fill 
the current request The catch phrase that handles the signal is expected to send back (i.e., return) an 
array descriptor for a block of storage to be added to the zone. The declaration of BlockTooLarge 
would look like 

BlockTooLarge: signal[2: Zone, needed: cardinal] 

REl\^RHS[newStorage: descriptor for array of cardinal]; 

A signal variable contains a unique name at run time, which is a code identifying an actual signal 
just as a procedure variable must be assigned an actual procedure before it can be used. If a 
procedure is imported from an interface (sec. 7.4), any signals that it generates directly are probably 
contained in the same interface. Imported signals are bound by the same mechanisms as procedures. 
In addition, one may have signal variables which can be assigned any signal value of a compatible 
type. 

The signal analog of an actual procedure is obtained by initializing a signal variable using the syntax 
"= code" in place of "= begin...end" for procedures. This causes the signal to be initialized to 
contain a unique value. The following syntax describes the initialization for an actual signal: 

Initialization ::= =code|... 

A signal is generated by using it in a SignalCall as shown in the syntax below: 
Statement ::= SignalCall |... 

SignalCall ::= signal Call [ErrorCall 

ErrorCall ::= return with error Call | 

ERROR Call I 
ERROR -- special error 

Call is defined in section 5.4, and the called Expression must have some signal type in this case. 
A SignalCall can be used as an Expression as well as a Statement. For example, 

newblock ^ signal BlockTooLarge[zone, /?]; 
Thus, generating a signal or error looks just like a procedure call, except for the additional word, 

ERROR or SIGNAL. 



Fine point: 



Although it is not recommended, the keywords SIGNAL and ERROR may be omitted (except in the RETURN 

WITH ERROR construct). This makes the signal look exactly like a procedure call. 

-<* 

Initiahzation by SIGNAL = CODE produces a unique value that contains, in part, the global frame index of the 
module containing the initialization. There are two points worth making. If one creates a copy of the module 
with the NEW statement, signals raised "by the two copies will be different. If the signal is declared and 
initialized in a procedure, recursive calls of the procedure will not generate different signal values. 
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If a signal is declared as an error, it must be generated by an ErrorCall. If, however, it is 
declared as a signal, it can be generated by any SignalCall, including an ErrorCall. The 
difference between the two is that a catch phrase may twi resume a signal generated by an 
ErrorCall (sec. 8.2.5). 

Hxcept for a slight difference in the way the error is started (sec. 8.2.3), the return with error 
construct behaves like the error statement. Its primary use is in monitor entry procedures 
(chapter 10). 

llie "special error" in the above syntax is used to indicate that something has gone wrong, without 
giving any indication of the cause; the statement 

error; 

generates a system-defmed error. It is provided to cover those "impossible" cases which should 
never occur in correct programs but which it is always best to check for (such as falling out of a 
loop that should never terminate normally, or arriving at the endcase of a select statement that 
claims to handle all the cases). It can only be caught using the any option in a catch phrase (sec. 
8.2.3). It is customarily handled by the debugger. 

8:1,1 error in expressions 

When an error is declared to return values, this is purely for syntactic convenience, since one of 
the principal features of an error is that it does not "return". The reason for doing this it to allow 
the ERROR to stand in an expression context considered invalid or impossible. Such declarations of 
returned values are not necessary; if an expression has an error type (or signal type raised as an 
error) and returns no value, then that expression can be used wherever an expression of any type is 
required. For example: 

Color: TYPE = {red, orange, yellow, green, blue, violet}', 
c: Color, 
button: [0..2); 

burton^ select c from 
red => 0, 
yellow => 1, 
blue => 2, 

endcase => ERROR; 

In the example, the only valid colors for buttons are red yellow, and blue. Any other value results in 
an error (in this case, the unnamed system error). Such constructs allow an inexpensive way to get 
to the debugger in those "impossible" cases that arise from program errors. 

A fine point: 

If the ERROR type is defined to return a value, any use of that expression must be type correct with respect to 
the "returned" value. 



8.2. Control of generated signals 

Any program which needs to handle signals must anticipate that need by providing catch phrases for 
the various signals that might be generated. During execution, certain of these catch phrases will be 
enabled at different times to handle signals. Loosely speaking, when a signal S is generated, the 
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procedures in the call hierarchy at that time will be given a chance to catch the signal in a last-in- 
first-out order. Each such procedure /\ if it has an enabled catch phrase, is given tlie signal S in 
turn, until one of them stops die signal from propagating any furUier (by mechanisms which are 
explained below). P may decide to reject S (in which case the next procedure in the call hierarchy 
will be considered), or P may decide to handle .V by taking control and attempting to recover from 
the signal. 

8.2 J. Preparing to catch signals: catch phrases 

A catch phrase has the following form: 

CatchTail :: = Catch | 

ANY => Statement 

Catch ::= ExpressionList => Statement 

CatchSeries ::= CatchTail | 

Catch ; CatchSeries 

The expressions in die ExpressionList (semantically restricted to a list of variables) must evaluate 
to the names of signals (unless otherwise stated, we use signal to stand for both error and signal). 
The special identifier any will match any signal (sec. 8.2.3). Note that if any occurs, it must be last. 

A catch phrase is written as part of an argument list, just after the last argument and before the right 
bracket. Catch phrases may appear in a procedure call, SignalCall, new, start, restart, stop, 
JOIN, FORK, or WAIT (but not in a resume or return). A catch phrase may also be appended to the 
BEGIN of a block or the do of a loop statement by means of an EnableClause. The applicable 
syntax for a call and for a block or loop statement is 

Call ::= Variable [ComponentList ! CatchSeries]] 

Variable [! CatchSeries ] I 

Block ::= begin -- (from Section 4.4) 

OpenClause 
EnableClause 
DeciarationSerles 
StatementSeries 
ExitsClause 

END 

EnableClause ::= empty] 

ENABLE Catchltem ; 1 

ENABLE BEGIN CatchSeries END ; ] 
ENABLE BEGIN CatchSerles ; end ; 

Note that the EnableClause is always followed by a semi-colon, and begin...end must be used if 
there is more than one Catch in an EnableClause. 

The main difference between the two kinds of catch phrases (enable and !) is the scope of their 
influence. A catch phrase on a Call is only enabled during that call. A catch phrase at the 
beginning of a compound or loop statement is enabled as long as control is in that block; it can 
catch a signal resulting from any call in the block (or generated in the block). 

To clarify the scope of influence of enable clauses, the following two diagrams are reproduced from 
chapter 4. The scope of each phrase extends over others with greater indentation. 
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BEGIN 

OpenClduse 

EnableClause 

OeclarationSeries 
StatementSeries 
ExitsClause 

END 

LoopControl 

DO 

OpenClause 

EnableClause 

StatementSeries 
LoopExltsClause 

ENDLOOP 

Note that catch phrases enabled in the EnableClause of a Block or LoopStmt are not in force 
in the ExitsClause or LoopExitsClause. 

Fine point: 

Procedures declared in the OeclarationSeries (of any enclosed Block) do not inherit the catch phrases in the 
EhabteClause (this is not shown by the diagrams). 

8.2,2. The scope of variables in catch phrases 

Catch phrases are called to handle signals (the exact mechanisms are discussed in the next section). 
The naming environment that exists when a catch phrase is called (in order of innermost to 
outermost scope) includes any parameters passed with that signal (these are declared as part of a 
signal's definition), and any variables to which the procedure or program activation containing the 
catch phrase has access. 

If a Catch has more than one label (or the label any), y^here the types of those labels are not 
identical then the signals arguments are not accessible in the Statement chosen by that Catch. 

If however, there is exactly one type for the signals named in a Catch's ExpressionList, then the 
signal's arguments are accessible in the statement following " = >". The names used are the 
parameters given in the signal's declaration, just as for procedures. For example, a catch phrase for 
signal BlockTooLarge (defined earlier) might be used in a section of code such as: 

" m StorageDefs 

BlockTooLarge'. SIGNAL [z: Zone, needed', cardinal] 

RETURNS[/76'wi7omg^: DESCRIPTOR FOR ARRAY OF cardinal]; 

GetMoreStorage: PROCEDURE [z: Zone, n: cardinal] 

RETURNS [descriptor FOR ARRAY OF cardinal]; 

-- in a user program 
/?: pointer TO v4ccow/7/; 

p *- Allocate[S\ZE[Account] \ 

BlockTooLarge => RESUt\AE[GetMoreStorag4.z. needed\]]\ 

The names 2 and needed in the catch phrase refer to the parameters passed along with the signal 
from Allocate (see sec. 8.2.5 for a discussion of resume). 
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8,2.3. Catching signals 



When a signal is generated, what really happens is that the signal code, and a descriptor for the 
actual arguments of the signal, are passed to a Mesa run-time procedure named Signaller. Signallers 
definition is 

Signaller: procedure[5: SignalCode, m: Message\\ 

Here s identifies the signal being generated, and m contains its arguments. (Actually, different 
procedures are used to distinguish between signal, error, and return with error.) 

Signaller proceeds to pass the signal and its argument record from one enabled catch phrase to the 
next in an orderly fashion. The order, at the procedure level, follows the cun*ent call hierarchy, 
from the most recently called procedure to least recently called, beginning with the procedure that 
generated the signal itself. If the caller of a procedure is the outermost block of code for a program, 
the Signaller will follow its return link to continue propagating the signal (the return link points to 
the frame that last STARTed the module (sec. 7.8)). 

If, in place of signal or error, a return with error is used, the procedure that generated the 
error is first deleted (after releasing the monitor lock, if it is an entry procedure), and propagation 
of the error begins with its caller. 

As S/gAi^/Zer considers each frame, it looks to see whetiier that frame has any enabled catch phrases; 
if so, S/gnaZ/er C(3//5 the innermost catch phrase as if it were a procedure, passing it the SignalCode 
and Message. The innermost catch phrase is defined to be 

either the one after "!" attached to the currently incomplete procedure call for that frame, or 

the one following an enable in the innermost enclosing block that contains that call. 

Because signals can be propagated right through the call hierarchy, the programmer must consider 
catching not only signals generated directly within any procedure that is called, but also any 
generated indirectly as a result of calling that procedure. Indirect signals are those generated by 
procedures called from within a procedure that you call, unless they are stopped before reaching 
you. 

When a catch phrase is called, it behaves like a select statement: it compares the signal code passed 
to it with each signal value in the EExpressionList of each Catch in the catch phrase. If the 
signal code matches one of the signal values, control enters the statement following the " = >" for 
that Catch; if not, the next Catch is tried. A Catch consisting of "any => Statement" 
automatically matches any signal code (and is the only way to catch the unnamed error generated 
by the standalone error statement discussed in section 8.1). 

Fine point: 

The ANY catchall is intended primarily for use by the debugger, and should generally be avoided. It matches 
any signal, including UNWIND and all system- defined signals that might indicate some catastrophic condition (a 
double memor\ parity error, for example). 

When a match is found, that Catch is said to have caught or accepted the signal. If no alternative 
in a catch phrase accepts the signal, there may be another enabled catch phrase in some surrounding 
block. If so, die first catch phrase sends control to the second one so that it can inspect the signal, 
and so on until the last enabled catch phrase in that routine has had a chance at the signal. If no 
catch phrase in the routine accepts the signal, control returns to Signaller with a value indicating that 
the signal was rejected, and Signaller propagates the signal to the next level in the call hierarchy. In 
fact, all catch phrases are called by Signaller as if they were procedures of the following type: 
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CaichPlnvse: procedure[s: SignalCode.ftK Message] 
RETURHS[{Reject, Unwind Resume}]: 

Hic SELECT-Iikc statement assoeiated with each Catch has an implicit Rejeet return as its endcase: 
hence, if control simply falls out of the statement, the signal is rejected. 

Fine point: 

If the same signal, foo, is enabled in se\eral nested catch phrases in a procedure, each is given a chance to 
handle foo if the inner ones reject the signal. 

Signaller continues propagating the signal up the call chain until it is exhausted, i.e., until the root of 
the process has considered and rejected the signal. At that point, an uncaught signal has been 
generated, and drastic action must be taken. 

Mesa guarantees that all signals will ultimately be caught and reported by the Debugger to the user. 
This is helpful in debugging because all the control context which existed when the signal was 
generated is still around and can be inspected to investigate the problem. 

The declaration of CatchPhrase above indicates three reasons for returning to Signaller. The first, 
Reject, has already been discussed. The third. Resume, is discussed in section 8.2.5. 

The second reason. Unwind, is used when a catch phrase has accepted a signal and is about to do 
some form of unconditional jump into the body of the routine containing it (this is the only form of 
"non-local goto" in Mesa). The jump may be generated by a goto statement (sec. 4.4), an exit or 
LOOP (sec. 4.5), or a retry or continue (see below), aslmmediately preceding such a jump, the 
catch phrase returns to Signaller with result Unwind', it also indicates the frame containing the catch 
phrase and the location for the jump. This causes Signaller to perform the following sequence of 
actions: 

(1) Beginning at the frame in which the original signal was generated (or its caller, if a 
RETURN WITH ERROR was executed), it passes the signal unwind to each frame. This signal 
tells that activation that it is about to be destroyed and gives it a chance to clean up before 
dying. Signaller then deallocates the frame and follows the same path as it did for the 
original signal to continue unwinding control. When it comes to the frame containing the 
catch phrase, it stops. 

(2) Signaller then arranges for the jump to take place, and simply does a return to that 
frame, destroying itself in the process. 

Every Mesa program contains the pre-declared value 

unwind: ERROR = CODE; 



Fine points: 



One cannot say RETURN in a catch phrase to return from the enclosing procedure. This is an implementation 
restriction that may be removed in the fijture, caused by the way in which a catch phrase is "called" like a 
procedure itself. 

The UNWIND sequence gives each activation that is to lose control a chance to make consistent any data 
structures for which it is responsible. There are no constraints on the kinds of statements that it can use to do 
this: procedure calls, loops, or whatever are all legal. If, however, a catch for the UNWIND signal, such as, 

START NextPhase [ ! UNWIND = > GOTO BailOut]: 

decides itself io perform a control transfer that would also initiate an UNWIND, this will override the original 
UNWIND, and Signaller will stop right there, as if the second UNWIND catch had been the originator of the 
UNWIND. 
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5.2.4. RETRY and continue /// calch phrases 

Besides goto. exit, and loop, tliere are two other statements, retry and continue, which initiate 
an unwind. These can only be used witliin catch phrases. 

RETRY means "go back to the beginning of the statement to which this catch phrase belongs": 
continue means "go to the statement /o/ZaHv/?^' the one to which this catch phrase belongs" (what is 
called Next-Statement in chapter 4). 

For a catch phrase in a Call, the catch phrase "belongs" to the statement containing that Call. 
ITius, if the signal NoAnswer is generated for the call below, the assignment statement is retried: 

answer *- GetRepIy[Send['V^hai next?"] ! NoAnswer => retry]; 

On the other hand, if continue had been used instead, the statement after the assignment would be 
executed next (and the assignment would not be performed). For example, suppose the procedure 
ReadLine reads characters from a file up to a carriage return and appends them onto the string 
buffer. If reading beyond the end of file raises the signal StreamError, the call 

ReadLine [ \ StreamError = > if buffer.length > then continue]; 

deals with the case of no carriage return after that last line in the file. If there is no such final line, 
other chatch phrases higher on the call chain are given a chance to catch the signal. 

For a catch phrase after enable, there are two cases to consider, blocks and loops. In a block, the 
catch phrase "belongs" to that statement; the next section shows an example. In a loop, the catch 
phrase "belongs" to the body of the loop, and continue really means "go around the loop again." 
The following two examples are equivalent: 

until /?=nil 

DO enable ro'L/s/2 => BEGIN /?^//s/2; continue end; 

endloop; 

until /7= nil 

DO 

BEGIN enable TryL/s/i => BEGiNp*" //sr2; continue; end; 

end; 
endloop; 

In any case, recall that an Unwind is initiated prior to completion of a retry or continue. 

If a procedure call in the Initialization clause of a declaration contains a catch phrase, this catch 
phrase cannot contain retry or continue since it is in no well defined statement. 

8.2.5. Resuming from a catch phrase: resume 

The third alternative available to a catch phrase, after Reject and Unwind, is Resume, This option is 
invoked by using the resume statement to return values (or perhaps just control) from a catch 
phrase to the routine which generated the signal. To that routine, it appears as if the signal call 
were a procedure call that returns some results. The syntax for resume is just like that for return: 

Statement ::= ResunneStmt| retry (continue | ... 

ResumeStmt :: = resume | 

RESUME [ConnponentUst ] 
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When Signaller receives a Resume from a catch phrase, it simply returns and passes the 
accompanying results to the routine that originally called it (i.e., that generated the signal). If die 
signal was generated by an ErrorCall and a catch phrase requests a Resume. Signaller simply 
generates a signal itself (which results in a recursive call on Signaller): its declaration is 

ResumeEnvr: PUBLIC ERROR: 

Since it is an error, one cannot legally resume it. 

^riie ability to resume and return values gi\ es die ability to deal with exceptional conditions in a 
way tliat is quite inexpensive in the non-exceptional case. For example, consider the declaration 

SmngBoundsFauli: signal [s: string] returns [//5.- string]; 

^rhis signal allows die user to deal with the situation where characters are to be added to a string 
diat is already "full". Thus the call 

AppendChar[str: c \ StringBoundsFault => 
begin 

ns ♦" AlIocateString[s,maxIenglh'¥lO]i 
Appends tring [ns, s]\ 
FreeStnng[s]\ 
RESUME[5/r <- ns]: 
END]; 

allocates a larger string and updates the local variable w^henever the string is about to overflow. Of 
course, the procedure AppendChar has to be written in such a way as to deal with the signal being 
resumed with a new string value. This application of signals can cause errors if there are any 
procedures between the signaller and the catcher that have their own idea about the location of the 
string. One possible fix (if such situations are possible) is to have a second signal 

StringMoved: SIGNAL [old, new: string] = CODE; 

that is raised by AppendChar after StringBoundsFault is resumed. 

The presence or absence of the ComponentList depends on whether the signal caught is declared 
to return values. In a Catch whose ExpressionList contains more than one signal, one can 
RESUME only if all signals have equivalent types. For example: 



ASig;. TYPE = 


SIGN AL RETURNS [CARDINAL] ; 


sigl: ASig: 






sigl'.ASig: 






sigh: SIGNAL returns [CARDINAL]; 




5/g4: SIGNAL; 






ENABLE 






BEGIN 






sigl, sigl 


= > RESUME[3]: 


- legal 


sighsigi 


=>resume[0]; 


- legal 


S/gl, 5/g4 


= >resume[1]; 


- illegal 


end; 







8.3. Signals within signals * 

What happens if, in the course of handling a signal, firstSignal a catch phrase (or some procedure 
called by it) generates another signal, seconds ignaH Handling nested signal generation is almost 
exactly like non-nested signal propagation. Generating the signal will call Signaller (recursively, 
since the instance of Signaller responsible for the first signal is still around), and it propagates the 
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new signal back through the call hierarchy by calling a second activation of Signaller, say 
'' SignaUeiT . When in the course of doing tliis it encounters the previous activation of Signaller 
CSignallerT), then something different must be done. 

\f firsts ignal is not the same as seconds ignaJ. Signaller} propagates it right through Signaller I. and 
all the activations beyond it are also given a chance to catch secondSignal 

On the other hand, if secondSignal - firstSignal then all of the routines whose frames lie beyond 
Signaller!, up to the frame containing the catch phrase called by Signallerh have already had a 
chance to handle firslSignah so they are not given it again. In order to skip around that section of 
the call hierarchy. Signaller! simply copies the appropriate state variables from SignallerL Next, 
Signaller} skips over the frame containing the catch phrase (by following its return link), and 
continues propagating secondSignal normally. 

For the programmer, the main import of nested signals is that one needs to consider, when writing a 
routine, not only what signals can be generated, directly or indirectly, by the called procedures, but 
also those which can be generated by catch phrases in that procedure or even the catch phrases of 
any calling procedures, also both directly or indirectly. 
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CHAPTER 9. 



PORTS AND CONTROL STRUCTURES * 



Mesa has, in addition to procedures, another mechanism by which programs may transfer control. 
This mechanism is called a port; ports allow separate modules or procedures to act as coroutines. 
When one calls a procedure and it returns, the procedure is finished; if the same operation is needed 
again, another call will create a new activation of it to perform that action. However, when a 
coroutine returns control, // does not finish and disappear. Calling it again only resumes it from 
where it left off. The advantage of a this scheme is that the coroutine may keep some of its state 
from call to call encoded in its program counter: i.e., if it is at a certain place in its code, then that 
place does not need to be encoded somehow and saved as a variable in order to decide how to 
proceed when next called. 

Actually, as described later, ports are normally used in pairs, just like electrical plugs and sockets, 
one for each side of the connection. If two coroutines A and B are connected, what is seen by A as 
a call to B appears to B as a return from A, and vice-versa. Thus, both A and B regard the other as 
a facility to be called to accomplish some processing task. For instance, if ReadFile is a coroutine 
for reading characters from a file which are then given, one at a time, to another coroutine, its view 
is that it reads characters from the file and calls the other coroutine to process them (in some 
unspecified way). WriteFile, on the other hand, a coroutine for writing characters into a file, would 
call a coroutine to get the next character to be written. Together these two coroutines could make a 
file copying program. 

A coroutine needs to be able to send arguments and to receive results. The language facilities for 
doing this closely mirror procedure parameter and result lists. For example, a port over which 
ReadFile could send a character would be declared by ReadFile as 

Out:PORj[ch\ character]; 

The port over which WriteFile receives a character, and which could be connected to ReadFile^s Out 
port, is declared as 

7/7: PORT returns[character]; 

There is only one other consequential difference between procedures and coroutines. A procedure 
can be called at any time because a new activation is created, which will always consume the 
arguments sent to it as soon as it begins. However, if two coroutines like ReadFile and WriteFile 
communicate, in order for the transfer of control and arguments to go smoothly, WriteFile must be 
prepared to receive a character when ReadFile sends it. Coroutines are not parallel processes, and 
one has to be started before the other, so it is guaranteed that the first attempt at transferring control 
between ReadFile and WriteFile will not work smoothly. Fortunately, Mesa provides a mechanism 
for starting a whole set of interconnected coroutines to get them past this start-up transient (sec. 9.2). 
The most important property of the mechanism is that the coroutines themselves need never be 
concerned about the startup transient - they are written as if it never happens. 
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9.1 . Syntax and an example of ports 

ITic syntax for declaring a port is the following: 

PortTC :: = 

PORT ParameterList ReturnsClause | 
RESPONDING PORT ParameterLlst ReturnsClause 

llie ParameterList and ReturnsClause may both be empty, just as for procedures. 
RESPONDING PORTS are covered in section 9.3. ITie syntax for making a call on a poit is exactly the 
same as for calls on procedures (both as statements and functions). 

The following pair of program modules implement the coroutines ReadFUe and WriteFile described 
earlier; they use the ports Out and ///, respectively: 

DIRECTORY 

FileDefs: from "filedefs" using [ 

NUL, File Handle, File Access, OpenFile, ReadChar, EndOfFile, CloseFile]\ 

ReadFUe: PROGRAM[/7am^: string] imports FileDefs = 

BEGIN OPEN FileDefs: 

Out: PORj[ch: character]; 

input: FileHandle: 

input <- OpenFile[name: name, access: FileAcces^Read\]: 

stop; 

um\L EndOJFil^input] 

DO 

Ou^ReadChai[input]]i -- PORT call: send a character from the file 

ENDLOOP; 
CloseFil^input]: 
Ou^NUL]\ '- send a null character to indicate end-of-file 

END. 
DIRECTORY 

FileDefs: from "filedefs" using [ 

NUL File Handle, File Access, OpenFile, WriteChar, CloseFile\\ 

WriteFile: PRO(^RM4.name: string] imports FileDefs = 

BEGIN OPEN FileDefs: 

In: PORT RETURNsfc/i: character]; 

char: CHARACTER; 

output: FileHandle: 

output ♦- OpenFile[name: name, access: FileAccess[Ne^^]]\ 

stop; 

DO -- until In sends a NUL 

char ^ //?[]; - PORT call: get a character 

IF char = NUL then exit; - check for end of stream 

WriteChar[ow//?w/, char]\ - write the character into the file 

ENDLOOP; 

CloseFile[output]\ 

END. 

ReadFUe first initializes its variables and opens the input file (with Read access). When it is 

restarted, it loops, reading characters from the file and sending them over its Out port until it 

reaches the end of the input file; then it sends a single NUL character. If it regains control, it 
simply returns. 
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WriteFile. after creating and opening a new output file, loops, reading characters from the port /// 
and writing them to the output. If it receives a NUL character, it closes the output file and returns. 
ITius, if ReadFile and WrUeFile^s ports were connected so that they were working together as 
coroutines. ReadFile would never regain" control after sending the NUL character. 

9.2. Creating and starting coroutines 

To set up the abo\e two programs as coroutines, their respective ports must be connected, and tlien 
they must be started individually, with the start-up transient handled. This is usually done by 
anodier, controlling program like the following: 

DIRECTORY 

TrapDefs: from "trapdefs" USING [Por/Faw//], 

lODefs: from "iodefs" using [ReadLine, WriteStringl 

ReadFile: from "readfile", 

WriteFile: from "writefile"; 

CopyMaker. program imports lODefs, reader: ReadFile, writer WriteFile - 

BEGIN OPEN IODefs\ 

input: STRING ♦- [256]; 

output: STRING ^ [256]; 

-- first ask the user for the names of the input and output files 

WriteStrin^'^dcm.^ofmp\xiTi\Q:''']\ReadLin^input]\ 

WriteStrin^''l<iamQ of output file: "]; ReadLin^output]; 

" create and initialize instances of ReadFile and WriteFile: 

START reader[input]\ 

START writer[output]: 

" connect their ports and then restart them to get them synchronized 

COHHECT writeKlnTO reader.Out', 

CONHECT reader.Out TO writer.In: 

RESTART writef{ \TrapDefs.PortFault =>COmmuE]\ 

RESTART readei ! TrapDefs.PortFault = > ERROR]; 

END. 

Logically, CopyMaker is a very simple program. However, it must know how to start ReadFile and 
WriteFile and how to connect their ports (and it must handle the signal PortFault -- see below). 
This is typical of the use of ports: the coroutines themselves do not know (nor should they care) 
exactly which other program(s) they are connected to; each port is viewed as a virtual facility to be 
called to perform some task, such as providing the next input or taking an output. 

CopyMaker first requests the names for the input file to be copied and the output file to which it 
should be copied. The names are read into the string variables input and output. Then an instance 
of ReadFile is made and initialized. Similarly, an instance of WriteFile is created and STARTed. 
When the news are perfonned, pointers to the instances are stored (into reader and writer above). 

After both instances have been created and initialized, CopyMaker perfonns the operations to get 
them past the startup transient. First it connects writer.In (i.e., WriteFile's In port) to readenOut: 
this simply amounts to storing a pointer in writer, In to the PORT readenOut. Then it connects 
reader. Out to writer.In. 



Fine point: 



The STARTS must be performed before the ports are connected. In general, it is not legal to access a module's 
variables before it has been started (and the variables have been initialized). Calls to procedures are allowed, 
however: they are handled by the start trap mechanism (sec. 7.8.3). 
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Once the connects are done, all that remains is to get the two coroutines synchronized. First, 
WrileFile is RESTARTed; it makes a port call on /// to get the first character to be written into the 
file. 

Tlie port call almost works because In is connected to another port. But, since ReadFile is not 
waiting for control to return over its Out port, it doesn't quite work. This fact is detected because a 
part of the underlying representation of Out indicates that no instance is pending on it (i.e., w^aiting 
to receive control via Out). This results in a trap, which is quickly converted into the error 
PortFauIt. CopyMaker clearly anticipated tliis as part of the normal startup transient (as evidenced 
by the presence of the catch phrase on the start statement). The continue in that catch phrase 
means: "forget about tliis signal and continue execution at tlie next statement in CopyMaker." 

The next action taken by CopyMaker is to restart ReadFile, ReadFile reads the first character 
from the input file and attempts a port call on Out, passing the character as its argument. This is 
the end of startup transients: this port call works. It works because WriteFile was left pending on In 
when it attempted to call it, even though that call did not go through completely. Since WriteFile is 
pending on In, it resumes, stores the argument in char, and proceeds. From now on, port calls 
between ReadFile and WriteFile will go smoothly, with no further intervention by CopyMaker. 
(Moreover, a port call is more efficient than a procedure call because no frames are allocated and 
deallocated in the process). 

When there are no more characters in the input file, ReadFile sends a final NUL character which 
causes WriteFile to close the output file and to return. This returns control to CopyMaker, who, in 
this example, also returns. 

The above description skipped one or two important details of the startup process and port calls. 
The next section corrects those omissions and discusses the underlying representation of ports. 

9.2.7. The CONNECT statement 

The first connect statement in CopyMaker is equivalent to the following (illegal) assignment: 
writer. In Jink *• @.reader.Out\ 

This assignment is illegal because, at the language level, a port does not look like a record with a 
link component. Nevertheless, the code produced by the compiler for the connect statement in 
CopyMaker performs exactly this assignment (the compiler is allowed to treat ports in terms of their 
underlying representations, without regard to type - it implements type checking). Note that 
CONNECT is not a symmetric operation: it only connects in one direction. 

The syntax for connect is the following: 

ConnectStmt ::= connect expression to expression 

These expressions must both be valid leftSides. The first expression must conform to some port 
type, and the second may conform to either a port or a procedure type (see sec. 9.2.2 for a 
discussion of ports connected to procedures). 

The types of die two expressions must be port-compatible. To be port-compatible, the result list of 
one must be compatible (see definition in sec. 5.2) with the parameter list of die other, and vice 
versa. This basically says that the first port sends what the second expects to receive, and the second 
sends what the first expects to receive. 

Fine point: 

In the present compiler, the CONNECT statement is not implemented 
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9.22 Low-level actions during a PORT call 

A PORT is represented as a record with two components, one of which is a pointer to another port, 
and one of which points to a frame (the frame which is pending on that port). Its definition is: 

Porn TYPE = MACHINE DEPENDENT RECORD 
[ 

frame: pointer to frame. -- internal view of a frame 
link: select overlaid * from 

null => [value: NullControlLink], 

port =>[portDesc: pointer to Port], 

procedure => [procDesc: ProcedureDescriptor\ 

ENDCASE 

I; 

We will not discuss the internal format of the types Frame, ProcedureDescripior, or NullControlLink 
here. The first two are the underlying representations for a frame and a procedure value, 
respectively. The last is just a special value which is used to initiate a trap if the port is used 
without having been connected first. 

The variant part of a Port distinguishes three cases (how these cases are identified is a function of 
the underlying implementation). The null case is how a Port v^hkh has not been connected is 
represented; it is what causes a trap if a call on the port is made before it is connected (this is called 
a linkage fault). If the Port is connected to another Port (the normal case), then the port variant 
holds. 

Procedure calls, port calls, and returns are all examples of control transfers: each suspends the 
execution of one activation and transfers control to another. They also perform other actions, such 
as creating or destroying frames, etc. Every control transfer from one activation to another has a 
source control link and a destination control link. By control link we mean a procedure value, a 
pointer to a port, or a pointer to a frame. 

All the high level control transfers in Mesa are built from one common, low-level mechanism called 
XFER, which effects the transfer from a source to a destination. In fact, it is possible to bind any 
form of control link, to any other; thus, if the program uses a port, it could be bound to a 
procedure, and calls on the port would actually result in calls on the procedure. A return from the 
procedure would cause control to come back in through the port. Similarly, a procedure value could 
contain a pointer to a port, in which case calls on that "procedure" would actually result in a port 
transfer via the destination port to the coroutine pending on it. 

The common part of a Port record is used when control is returning over a port. When a coroutine 
does a port call and is suspended, a pointer to its frame is assigned to the frame component of that 
port. Then, when control returns over that port (usually because of a port call on die port to which 
it is connected), the frame field is used to locate the instance which is to be resumed. 

The value contained in the frame component may indicate that it is nulL If so, a control fault trap 
will be generated should a transfer using that port ever occur. This condition can arise for two 
different reasons: 

(1) Due to startup transients, the instance which would normally be pending on that port is not. 

(2) There is a genuine error in the way that a configuration of coroutines has been constructed, 
and control is attempting to "loop back" into a coroutine. The simplest example of this 
situation is the following: consider a coroutine A with two ports, pi and p2. If pi were 
connected to p2, then a port call on pi would clearly result in a control fault when p2 was 
reached in the call, since A cannot be pending on both pi and p2 simultaneously. 
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llie action taken on a control fault during a port call is described in the next section. 

Iliere is one last important detail about a port call: as part of the action of returning to a port, its 
link is set to point at the source port if the return is actually part of a port call. ITiis constitutes an 
indirect return link. However, if the return is from a procedure to which the port is bound, tlien the 
link field is not changed. This is so that the procedure value in the port is not destroyed: thus, 
future calls on that port will always result in new activations of that procedure. 

Storing an indirect return link in the link field of a destination port means that tlie next port call on 
it will cause control to return via the port from which control most recently arrived. Using this, one 
can write coroutines that may be invoked by more dian one coroutine connected to a given port: 
control will always return to the last coroutine which sent control over that port. For instance, the 
coroutine WriteFile above could be given its input stream of characters from many sources. If tbe 
system procedures ReadLine and WriteString both had ports connected to the port In in an instance 
of WriteFile, then everything typed to the user and typed by him would be recorded in a typescript 
of his interactions with the system. 

9,23, Control faults and linkage faults 

When a control or a linkage fault occurs, Mesa changes the trap into the error PortFault or 
LinkageFaulu respectively. These signals are part of a Mesa system interface TrapDefs and should 
be imported from there by any program, such as CopyMaker, which configures coroutines. In 
TrapDefs they are defined as follows: 

PortFault, LinkageFault: error; 

Generally, programs should not handle the LinkageFault signal; ports should be properly connected 
before they are used. We include it here only for completeness (the fine point at the end of this 
section discusses LinkageFaults further). 

These signals, unlike most other signals, are not passed initially to the instance which caused the 
fault (call it the culprit), but rather are given first to its owner: the frame to which the culprit's 
return link points. This is so that the owner may catch the signal and cause an unwind without the 
culprit's frame being destroyed as it would normally be. In the previous example, CopyMaker is the 
owner and ReadFile and WriteFile are possible culprits. 

Note: if the owner does not catch the PortFault or the LinkageFault signal it may possibly be 
unwound itself This would leave the culprit ^s return link pointing to an invalid address, because the 
ownefs frame would have been freed. 

The standard action taken by the owner when receiving a PortFault while starting a coroutine is to 
press on and start the other members of the configuration. CopyMaker follows this pattern; when it 
starts the instance of WriteFile and a control fault is generated, it simply exits the catch phrase for 
PortFault and starts the instance of ReadFile. This is the recommended way to start configurations of 
coroutines. 



Fine point: 



If the source port in a port call is unbound (i.e.. not connected), a LinkageFault ERROR is generated. This 
cannot be handled in the same manner as a control fault. If the catcher of this signal causes an UNWIND, 
there will be no way to restart the activation which caused the linkage fault: it will be pending on a port, and 
RESTARTing it will cause an error. This difficulty makes starting coroutines before connecting their ports an 
ill-advised thing to do. It is much better to do the CONNECTS first, and then start each activation. 



1 50 Chapter 9: Ports and Contro] Structures 

9,2.4. Saving arguments during faults 

When a port call faults, the instance which atteinpted the call is left pending on the source port 
before the trap is changed into the Port Fault or LinkageFauIt signal, lliis is done by a Mesa 
procedure called the Fault Handler which is called in response to the trap. In the case of starting 
writer above, this procedure did the following: 

(1) It set the instance of WriteFile to be pending on its In port (the trap process provides 
information about which instance caused die trap, and what the source port was); 

(2) By some low-level control mechanisms, it invoked the Signaller (sec. 8.2) as if from the 
owner of writer and simultaneously did a return. Thus, that activation of FaultHandler 
disappeared and the Signaller was invoked as a single action. 

Later, when reader called Out, control returned to writer via In, which continued normally because it 
was pending on In. To writer it appeared as if the first port call worked correctly. 

Readers call on Out passed an argument along with control. If CopyMaker had started reader first, 
what would have happened to that argument? Given the above description o/ FaultHandler, the 
argument would have been lost: there were no provisions for buffering or saving arguments. 

To handle this, the FaultHandler buffers any arguments passed over a port on which a fault occurs. 
Instead of performing action (2) above, it actually does die following: 

(2') It buffers the arguments for the port call, makes it appear that it (the FaultHandler itself) is 
pending on the source port, then calls Signaller, but without destroying itself in doing so. 

For the following discussion, assume that the startup sequence in CopyMaker had been written as 
follows (the order of starting reader and writer has been inverted): 

- connect their ports and then restart them to get them synchronized 

COHt^ECT reader.Out JO writer.In', 

CONNECT writer. In TO reader.Out\ 

RESTART readei[ ! TrapDefs.PortFault => continue]; 

RESl ^PJ writef[\TrapDefs.PortFault=>ERnOP(\\ 

END. 

The re\ised version of FaultHandler would then do the following when writer was RESTARTed and 
tried its first call on In: 

The instance of FaultHandler which had left itself pending on Out would have been 
resumed instead of reader. FaultHandler would then have set reader.Oulframe so that reader 
was again pending on it. Finally, it would have transferred control back through writer. In 
along with the arguments it had saved from the original call, destroying itself in the process. 

The only remaining question is: "How does the FaultHandler know whether or not arguments 
should be buffered?" This question is not trivial: for example, if every instance of FaultHandler 
buffered arguments for every trapped port call including those for ports like In, extra "ghost" port 
calls would occur during startup. FaultHandler determines whether or not to save arguments by 
inspecting information left by the compiler in the object code of every port call. This decision is 
made by the compiler on the following basis: 

Arguments should only be buffered for a port which is not a responding port and which 
does have a non-empty ParameterList. 

The next section discusses responding ports. 
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9.3. RESPONDING PORTS * 



ITie nornial analogy between a port and a procedure in terms of passing arguments and receiving 
results breaks down in one case. If a port is used both for sending arguments and for receiving 
results, it might do so for either of tlie following two reasons: 



*C5 



It sends arguments to be processed, and tlie returned results of the port call indicate how 
tliey were handled (this closely mirrors procedures). 

It receives data to be processed, and, having done so responds by sending results of the 
processing back over the same port (there is no procedure analog of this). 

The second case can not be distinguished from the first by usage in a program because the actions of 
sending and receiving over a port are intrinsically intertwined with the notation for a Call. Thus, it 
would not be possible to determine whether BothWays was a normal or a responding port by 
looking at the following (partial) module: 

BothWays: pqri{s\ string] returns[/: string]; 
aString: string; 
bSthng: string; 

aSthng ^ BothWays[bStringY 

To resolve this difficulty, the programmer may declare a port to be responding. For example, 
InOut: RESPONDING PORT[response: {okay, error}] RETURNS[m/?w/: string]; 

The module using InOut responds with either okay or notOkay to each string it has received. 

If InOut faults the first time it is used, the FauUHandler will not buffer the response value for that 
call. Since InOut must, for type conformance, be connected to a port such as 

Outhr. POK\[output\ string] RETURNS[r^s/?(?A25^: {okay, error}], 

both initial argument lists (the response for the first call on InOuU and the output of the first call on 
Outin) cannot be buffered. The keyword responding indicates which initial argument list should 
be discarded (InOut's initial response, in this case). For similar reasons, a responding port may not 
be connected to a procedure, and two responding ports may not be connected together. 

Fine point: 

In the current compiler, RESPONDING PORTs are not implemented 
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CHAPTER 10. 



PROCESSES AND CONCURRENCY 



Mesa provides language support for concurrent execution of multiple processes. This allows 
programs that are inherently parallel in nature to be clearly expressed. The language also provides 
facilities for synchronizing such processes by means of entry to monitors and waiting on condition 
variables. 

The next section discusses the forking and joining of concurrent process. Later sections deal with 
monitors, how their locks are specified, and how they are entered and exited. Condition variables 
are discussed, along with their associated operations. 



10.1. Concurrent execution, fork and join. 

The FORK and join statements allow parallel execution of two procedures. Their use also requires 
the new data type process. Since the Mesa process facilities provide considerable flexibility, it is 
easiest to understand them by first looking at a simple example. 

10 J. L A process example 

Consider an application with a front-end routine providing interactive composition and editing of 
input lines: 

ReadLine: procedure [s: string] returns [cardinal] = 

BEGIN 

c: character; 
sJength <- 0; 
DO 

c*- ReadCha^\ 

\f ControlCharactei[c]lHEHDoAction[c] 

ELSE AppendChar[5,c]; 

IF c = CR THEN return [sJength]: 

ENDLOOP; 

end; 

The call 

n ^ ReadLin^buffer\\ 

will collect a line of user type-in up to a CR and put it in some string named buffer. Of course, the 
caller cannot get anything else accomplished during the type-in of the line. If there is anything else 
diat needs doing, it can be done concurrently with the type-in by forking io ReadLine instead of 
calling it: 
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p ^ FORK ReadLm^buffei]\ 
<concurrent computation> 

n ♦- JOIN p; 

ITiis allows the statements labeled <concuiTent computation> to proceed in parallel with user typing 
(clearly, the concurrent computation should not reference the string buffer). The fork constmct 
spaw^ns a new process whose result type matches that of ReadLine. (ReadLine is referred to as the 
"root procedure" of the new process.) 

p: PROCESS RETURNS [CARDINAL]; 

Later, the results are retrieved by the join statement, which also deletes the spawned process. 
Obviously, this must not occur until both processes are ready (i.e. have reached the join and the 
RETURN, respectively); this rendevous is synchronized automatically by the process facility.- 

Note that the types of the arguments and results of ReadLine are always checked at compile time, 
whether it is called or forked. 

The one major difference between calling a procedure and forking to it is in the handling of signals; 
see section 10.5.1 for details. 

10,1.2, Process language constructs 

The declaration of a process is similar to the declaration of a procedure, except that only the 
return record is specified. The syntax is formally specified as follows: 



TypeConstructor 
ProcessTC 
ReturnsClause 
ResultList 



= ... I ProcessTC 

= process ReturnsClause 

= empty I returns ResultList - from sec. 5.1. 

= FieldList -- from sec. 5.1. 



Suppose that /is a procedure and p a process. In order to fork /and assign the resulting process to 
/?, the ReturnClause of /and that of p must be compatible, as described in sec 5.2. 

The syntax for the fork and join statements is straightforward: 



Statement 

Expression 

ForkCall 

JoinCall 

Call 



= ... I JoinCall 

= ... I ForkCall I JoinCall 

= fork Call 

= join Call 

= (see sections 5.4 and 8.2.1) 



The ForkCall always returns a value (of type process) and thus a fork cannot stand alone as a 
statement. Unlike a procedure call, which returns a record, the value of the fork cannot be 
discarded by writing an empty extractor. The action specified by the fork is to spawn a process 
parallel to the current one, and to begin it executing the named procedure. 
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llic JoinCail appears as either a statement or an expression, depending upon whether or not the 
process being joined has an empty ReturnsClause. It has the following meaning: When the 
forked procedure has executed a return and the join is executed (in either order), 

the returning process is deleted, and 

the joining process receives the results, and continues execution. 

A catch phrase can be attached to either a fork or join by specifying it in the Call. Note, 
nowever. that such a catch phrase does not catch signals incurred during the execution of the 
procedure: see section 10.5.1 for further details. 

Tliere are several other important similarities with normal procedure calls which are worth noting: 

The types of all arguments and results are checked at compile time. 

There is no intrinsic rule against multiple activations (calls and/or forks) of the same 
procedure coexisting at once. Of course, it is always possible to write procedures which will 
work incorrecdy if used in this way, but the mechanism itself does not prohibit such use. 

One expected pattern of usage of the above mechanism is to place a matching fork/join pair at the 
beginning and end of a single textual unit (i.e. procedure, compound statement, etc.) so that the 
computation within the textual unit occurs in parallel with that of the spawned process. This style is 
encouraged, but is not mandatory; in fact, the matching fork and join need not even be done by 
the same process. Care must be taken, of course, to insure that each spawned process is joined only 
once, since the result of joining an already deleted process is undefined. Note that the spawned 
process always begins and ends its life in the same textual unit (i.e. the target procedure of the 
fork). 

While many processes will tend to follow the fork/ join paradigm, there will be others whose role is 
better cast as continuing provision of services, rather than one-time calculation of results. Such a 
"detached" process is never joined. If its lifetime is bounded at all, its deletion is a private matter, 
since it involves neither synchronization nor delivery of results. No language features are required 
for this operation; see the runtime documentation for the description of the system procedure 
provided for detaching a process. 



10.2. Monitors 

Generally, when two or more processes are cooperating, they need to interact in more complicated 
ways than simply forking and joining. Some more general mechanism is needed to allow orderly, 
synchronized interaction among processes. The interprocess synchronization mechanism provided in 
Mesa is a variant of monitors adapted from the work of Hoare, Brinch Hansen, and Dijkstra. The 
underlying view is that interaction among processes always reduces to carefully synchronized access 
to shared data, and that a proper vehicle for this interaction is one which unifies: 

- the synchronization 

- the shared data 

- the body of code which performs the accesses 

The Mesa monitor facility allows considerable flexibility in its use. Before getting into die details, 
let us first look at a slighdy over-simplified description of the mechanism and a simple example. 
The remainder of this section deals with the basics of monitors (more complex uses are described in 
section 10.4); wait and notify are described in section 10.3. 
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10.2.1. An overview of monitors 



A monitor is a module instance. It thus has its own data in its global frame, and its own procedures 
for accessing tliat data. Some of the procedures are public, allowing calls into the monitor from 
outside. Obviously, conflicts could arise if two processes were executing in the same monitor at the 
same time. To prevent this, a monitor lock is used for mutual exclusion (i.e. to insure that only one 
process may be in each monitor at any one time). A call into a monitor (to an entry' procedure) 
implicitly acquires its lock (waiting if necessary), and returning from the monitor releases it. The 
monitor lock ser\ es to guarantee the integrity of the global data, which is expressed as the monitor 
invariant - i.e an assertion defining what constitutes a "good state" of the data for that particular 
monitor. It is the responsibility of evety entry procedure to restore the monitor invariant before 
returning, for the benefit of the next process entering the monitor. 

Things are complicated slightly by the possibility that one process may enter the monitor and find 
that the monitor data, while in a good state, nevertheless indicates that that process cannot continue 
until some other process enters the monitor and improves the situation. The wait operation allows 
the first process to release the monitor lock and await the desired condition. The wait is performed 
on a condition variable, which is associated by agreement with the actual condition needed. When 
another process makes that condition true, it will perform a notify on the condition variable, and 
the waiting process will continue from where it left off (after reacquiring the lock, of course.) 

For example, consider a fixed block storage allocator providing two entry procedures: Allocate and 
Free. A caller of Allocate may find the ft*ee storage exhausted and be obliged to wait until some 
caller of Free returns a block of storage. 

Storage Allocator, monitor = 

BEGIN 

Storage Available, condition; 
FreeList: POM\ER\ 

Allocate', entry procedure returns [p: pointer] = 
begin 
WHILE FreeList = nil do 

WAIT Storage Available 

endloop; 
p <- FreeList; FreeList <- p.next] 
end; 

Free: entry procedure [p: pointer] = 

BEGIN 

p.next <- FreeList; FreeList ^ p\ 

NOT\f\ Storage Available 

end; 

END. 

Note that it is clearly undesirable for two asynchonous processes to be executing in the 
Storage Allocator at the same time. The use of entry procedures for Allocate and Free assures 
mutual exclusion. The monitor lock is released while WAiTing in Allocate in order to allow Free to 
be called (this also allows other processes to call Allocate as well, leading to several processes 
waiting on the queue for StorageAvailable). 
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10:2,2. Monitor locks 

The most basic component of a monitor is its monitor lock. A monitor lock is a predefined type, 
which can be thought of as a small record: 

monitorlock: type = private record [locked: boolean, queue: Queue]: 

The monitor lock is private; its fields are never accessed explicitly by the Mesa programmer. 
Instead, it is used implicitly to synchronize entr\' into the monitor code, thereby authorizing access 
to the monitor data (and in some cases, other resources, such as I/O devices, etc.) The next section 
describes several kinds of monitors which can be constructed from this basic mechanism. In all of 
these, the idea is the same: during entry to a monitor, it is necessary to acquire the monitor lock by: 

1. waiting (in the queue) until: locked = false, 

2. setting: locked ^ true. 

10,2.3. Declaring monitor modules, entry and internal procedures 

In addition to a collection of data and an associated lock, a monitor contains a set of procedures that 
do operations on the data. Monitor modules are declared much like program or definitions modules; 
for example: 

A/: monitor [arguments] = 
begin 

end. 

The procedures in a monitor module are of three kinds: 

Entry procedures 

Internal procedures 

External procedures 

Every monitor has one or more entry' procedures; these acquire the monitor lock when called, and 
are declared as: ; 

P: EHTRY PROCEDURE [arguments] = ... 

The entry procedures will usually comprise the set of public procedures visible to clients of the 
monitor module. (There are some situations in which this is not the case; see external procedures, 
below). The usual Mesa default rules for public and private procedures apply. 

Many monitors will also have internal procedures: common routines shared among the several entry 
procedures. These execute with the monitor lock held, and may thus freely access the monitor data 
(including condition variables) as necessary. Internal procedures should be private, since direct calls 
to them from outside the monitor would bypass the acquisition of the lock (for monitors 
implemented as multiple modules, this is not quite right; see section 10.4, below), internal 
procedures can be called only from an entry procedure or another internal procedure. They are 
declared as follows: 

Q: INTERNAL PROCEDURE [arguments] = ... 
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'Ilie attributes entry or internal may be specified on a procedure only in a monitor module. 
Section 10.2.4 describes how one declares an interface for a monitor. 

Some monitor modules may wish to have external procedures. These are declared as normal non- 
monitor procedures: 

R: PROCEDURE [arguments] = . . . 

Such procedures are logically outside the monitor, but are declared within the same module for 
reasons of logical packaging. For example, a public external procedure might do some preliminary 
processing and then make repeated calls into^ the monitor proper (via a private entry procedure) 
before returning to its client. Being outside the monitor, an external procedure must not reference 
any monitor data (including condition variables), nor call any internal procedures. The compiler 
checks for calls to internal procedures and usage of the condition variable operations (wait, notify, 
etc.) within external procedures, but does not check for accesses to monitor data. 

A fine point: 

Actually, unchanging read-only global variables may be accessed by external procedures: it is changeable monitor 
data that is strictly off-limits. 

Generally speaking, a chain of procedure calls involving a monitor module has the general form: 

Client procedure -■ outside module 

External procedure(s) -- inside module but outside monitor 

Entry procedure -- inside monitor 

Internal procedure(s) -- inside monitor 

Any deviation from this pattern is likely to be a mistake. A useful technique to avoid bugs and 
increase the readibility of a monitor module is to structure the source text in the corresponding 
order: 

A/: MONITOR = 
BEGIN 

<External procedures> 
<Entry procedures> 
<Internal procedures> 
<Initialization (main-body) code> 

END. 

10.2,4, Interfaces to monitors 

In Mesa, the attributes entry and internal are associated with a procedure's body, not with its 
type. Thus they cannot be specified in a definitions module. Typically, internal procedures are not 
exported anyway, although they may be for a multi-module monitor (see section 10.4.4). In fact, the 
compiler will issue a warning when the combination public internal occurs. 

From the client side of an interface, a monitor appears to be a normal program module, hence the 
keywords monitor and entry do not appear. For example, a monitor M with entry procedures P 
and Q might appear as: 



1 58 Chapter 1 0: Processes and Concurrency 

MDefs: definitions = 

BEGIN 

A/: PROGRAM [argumentsY 

P. Q\ PROCEDURE [arguments] RETURNS [resuUsY 

END. 

10.2.5. Interactions of processes and monitors 

One interaction should be noted between the process spawning and monitor mechanisms as defined 
so far. If a process executing within a monitor forked to an internal procedure of the same monitor, 
the result would be two processes inside the monitor at the same time, which is the exact situation 
that monitors are supposed to avoid. The following rule is therefore enforced: 

A FORK may have as its target any procedure except an internal procedure of a monitor. 

A fine point: 

In the case of a multi-module monitor (see section 10.4.4) calls to other monitor procedures through an interface 
cannot be checked for the INTERNAL attribute, since this information is not available in the interface (see 
section 10.2.4). 



10.3. Condition Variables 

Condition variables are declared as: 

c: CONDITION; 

The content of a condition variable is private to the process mechanism; condition variables may be 
accessed only via the operations defined below. It is important to note that it is the condition 
variable which is the basic construct; a condition (i.e. the contents of a condition variable) should not 
itself be thought of as a meaningflil object; it may /20/be assigned to a condition variable, passed as 
a parameter, etc. 

10.3.1. WaiU notify, and broadcast 

A process executing in a monitor may find some condition of the monitor data which forces it to 
wait until another process enters the monitor and improves the situation. This can be accomplished 
using a condition variable, and the three basic operations: wait, notify, and broadcast, defined by 
the following syntax: 

Statement ::=... |WaitStnnt| NotlfyStmt 

WaitStmt ::= wait Variable OptCatchPh rase 

NotlfyStmt ::= notify Variable | broadcast Variable 

A condition variable c is always associated with some Boolean expression describing a desired state 
of the monitor data, yielding the general pattern: 

Process waiting for condition: 

WHILE -^BooleanExpresslon do 

WAIT C 
ENDLOOP; 
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Process making condition tnie: 

make BooleanExpression true; -- i.e. as side effect of modifying global data 
NOTIFY c; 

Consider the storage allocator example from section 10.2.1. In this case, the desired 
BooleanExpression is ''FreeList # nil". Hiere are several important points regarding wait and 
NOTIFY, some of which are illustrated by that example: 

WAIT always releases the lock while waiting, in order to allow entry by other processes, 
including die process which will do the notify (e.g. Allocate must not lock out the caller of 
Free while waiting, or a deadlock will result). Thus, the programmer is always obliged to 
restore the monitor invariant (return the monitor data to a "good state") before doing a 

WAIT. 

NOTIFY, on the other hand, retains the lock, and may thus be invoked without restoring the 
invariant; the monitor data may be left in in an arbitrary state, so long as the invariant is 
restored before the next time the lock is released (by exiting an entry procedure, for 
example). 

A NOTIFY directed to a condition variable on which no one is waiting is simply discarded. 
Moreover, the built-in test for this case is more efficient than any explicit test that the 
programmer could make to avoid doing the extra notify. (Thus, in the example above. Free 
always does a notify, without attempting to determine if it was actually needed.) 

Each WAIT must be embedded in a loop checking the corresponding condition. (E.g. 
Allocate, upon being notified of the StorageAvailable condiiion, still loops back and tests 
again to insure that the freelist is actually non-empty.) This rechecking is necessary because 
the condition, even if true when the notify is done, may become false again by the time the 
awakened process gets to run. (Even though the freelist is always non-empty when Free 
does its NOTIFY, a third process could have called Allocate and emptied the freelist before 
the waiting process got a chance to inspect it.) 

Given that a process awakening from a wait must be careful to recheck its desired 
condition, the process doing the notify can be somewhat more casual about insuring that 
the condition is actually true when it does the notify. This leads to the notion of a covering 
condition variable, which is notified whenever the condition desired by the waiting process is 
likely to be true; this approach is useful if the expected cost of false alarms (i.e. extra 
wakeups that test the condition and wait again) is lower than the cost of having the notifier 
always know precisely what the w^aiter is waiting for. 

The last two points are somewhat subtie, but quite important; condition variables in Mesa act as 
suggestions that their associated Boolean expressions are likely to be true and should therefore be 
rechecked. They do not guarantee that a process, upon awakening from a wait, will necessarily find 
the condition it expects. The programmer should never write code which implicitiy assumes die 
truth of some condition simply because a notify has occurred. 

It is often the case that the user will wish to notify all processes waiting on a condition variable. 
This can be done using: 

BROADCAST c; 

This operation can be used when several of the waiting processes should run, or when some waiting 
process should run, but not necessarily the head of the queue. 
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Consider a variation of the Stcfrage Allocator example: 
Storage Allocator, monitor = 

BEGIN 

Storage Available'. CONDITION; 



Allocate: entry procedure [size: cardinal] returns [p: pointer] = 

BEGIN 

UNTIL <storage chunk of size words is available> DO 
WAIT StorageAvailable 

ENDLOOP; 

p <- <remove chunk of 5/z^ words>; 
end; 

Free: entry procedure [p: pointer, sfz^*: cardinal] = 

BEGIN 

<put back storage chunk of 5/z^ words> 

BROADCAST StorageAvailable 
end; 

END. 

In this example, there may be several processes waiting on the queue of StorageAvailable, each with 
a different size requirement. It is not sufficient to simply notify the head of the queue, since that 
process may not be satisfied with the newly available storage while another waiting process might be. 
This is a case in which broadcast is needed instead of notify. 

An important rule of thumb: // is always correct to use a broadcast, notify should be used instead 
of BROADCAST if both of the following conditions hold: 

It is expected that there will typically be several processes waiting in the condition variable 
queue (making it expensive to notify all of them with a broadcast), and 

It is known that the process at the head of the condition variable queue will always be the 
right one to respond to the situation (making the multiple notification unnecessary); 

If both of these conditions are met, a notify is sufficient, and may represent a significant efficiency 
improvement over a broadcast. The allocator example in section 10.2.1 is a situation in which 
NOTIFY is preferrable to broadcast. 

As described above, the condition variable mechanism, and the programs using it, are intended to be 
robust in the face of "extra" notifys. The next section explores the opposite problem: "missing" 

NOTIFYS. 

A fine point: 

When a program WAITs, it releases the monitor lock. When it returns from the wait, it reacquires the lock. 

The address of die condition variable has to be calculated twice. If this address is obtained by a complicated 

expression, there is a subtle restriction. The address calculation cannot do a WAIT in the same process. In 
other words, consider the procedure 
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CondProc: PROCEDURE RETURNS [POINTER TO CONDITION]; 
If a program contains the statement 

WAIT CondProcWf 
then the execution of CondProc cannot WAIT. 

10 J. 2. Timeouts 

One potential problem with waiting on a condition variable is the possibility that one may wait "too 
long/' There are several ways this could happen, including: 

- Hardware error (e.g. "lost interrupt") 

- Software error (e.g. failure to do a notify) 

- Communication error (e.g. lost packet) 

To handle such situations, waits on condition variables are allowed to time out. This is done by 
associating a timeout interval with each condition variable, which limits the delay that a process can 
experience on a given wait operation. If no notify has arrived within this time interval, one will be 
generated automatically. The Mesa language does not currently have a facility for setting the 
timeout field of a condition variable. See the runtime documentation for the description of the 
system procedure provided for this operation. 

The waiting process will perceive this event as a normal notify. (Some programs may wish to 
distinguish timeouts from normal notifys; this requires checking the time as well as the desired 
condition on each iteration of the loop.) 

No facility is provided to time out waits for monitor locks. This is because there would be, in 
general, no way to recover from such a timeout. 

10.4. More about Monitors 

The next few sections deal with the ftiU generality of monitor locks and monitors. 

lOJ.L The LOCKS clause 

Normally, a monitor's data comprises its global variables, protected by the special global variable 
LOCK: 

LOCK: monitorlock; 

This implicit variable is declared automatically in the global frame of any module whose heading is 
of the form: 

A/: monitor [arguments] 
IMPORTS ... 
EXPORTS . . . = 

In such a monitor it is generally not necessary to mention LOCK explicitly at all. For more general 
use of the monitor mechanism, it is necessary to declare at the beginning of the monitor module 
exactly which monitorlock is to be acquired by entry procedures. This declaration appears as part 
of the program type constructor that is at the head of die module. The syntax is as follows: 
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ProgramTC :: = ... | monitor ParameterList ReturnsClause LocksClause 

LocksClause :: = empty | locks Expression | 

LOCKS Expression using Identifier : TypeSpecification 

If the LocksClause is empty, entry to the monitor is controlled by the distinguished variable 
LOCK (automatically supplied by the compiler). Otherwise; the LocksClause must designate a 
variable of type monitorlock, a record containing a distinguished lock field (see section 10.4.2), or a 
pointer that can be dereferenced (perhaps several times) to yield one of the preceding. If a 
LocksClause is present, the compiler does not generate the variable LOCK. 

If the USING clause is absent, the lock is located by evaluating the locks expression in the context of 
the monitor's main body; i.e., the monitor's parameters, imports, and global variables are visible, as 
are any identifiers made accessible by a global open. Evaluation occurs upon entry to, and again 
upon exit from, the entry procedures (and for any waits in entry or internal procedures). The 
location of the designated lock can thus be affected by assignments within the procedure to variables 
in the locks expression. To avoid disaster, it is essential that each reevaluation yield a designator of 
the same monitorlock. This case is described further in section 10.4.4. 

If the using clause is present, the lock is located in the following way: every entry or internal 
procedure must have a parameter with the same identifier and a compatible type as that specified in 
the using clause. The occurrences of that identifier in the locks clause are bound to that 
procedure parameter in every entry procedure (and internal procedure doing a wait). The same care 
is necessary with respect to reevaluation; to emphasize this, the distinguished argument is treated as 
a read-only value within the body of the procedure. See section 10.4.5 for further details. 

10.4.2. Monitored records 

For situations in which the monitor data cannot simply be the global variables of the monitor 
module, a monitored record can be used: 

r MONITORED record [x: integer, ... ]; 

A monitored record is a normal Mesa record, except that it contains an automatically declared field 
of type monitorlock. As usual, the monitor lock is used implicitly to synchronize entry into the 
monitor code, which may then access the other fields in the monitored record. The fields of the 
monitored record must not be accessed except from within a monitor which first acquires its lock. 
In analogy with the global variable case, the monitor lock field in a monitored record is given the 
special name LOCK, generally, it need not be referred to explicidy (except during initialization; see 
section 10.6). 

A fine point: 

A more general form of monitor lock declaration is discussed in section 10.4.6 

CAUTlox: If a monitored record is to be passed around (e.g. as an argument to a procedure) this 
should always be done by reference using a pointer to monitored record. Copying a monitored 
record (e.g. passing it by value) will generally lead to chaos. 

10.4.3. Monitors and module instances 

Even when all the procedures of a monitor are in one module, it is not quite correct to think of the 
module and the monitor as identical. For one thing, a monitor module, like an ordinary program 
module, may have several instances. In the most straightforward case, each instance constitutes a 
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separate monitor. More generally, through tlie use of monitored records, the number of monitors 
may be larger or smaller than the number of instances of the corresponding module(s). The crucial 
observation is that in all cases: 

There is a one-to-one correspondence between monitors and monitor locks, 

Tlie generalization of monitors through the use of monitored records tends to follow one of two 
patterns: 

Multi-module monitors, in which several module instances implement a single monitor. 

Object monitors, in which a single module instance implements several monitors. 

A fine point: 

These two patterns are not mutually exclusive: multi-module object monitors are possible, and may occasionally 
prove necessary. 

10,4.4, Multi-module monitors 

In implementing a monitor, the most obvious approach is to package all the data and procedures of 
the monitor within a single module instance (if there are multiple instances of such a module, they 
constitute separate monitors and share nothing except code.) While this will doubtless be the most 
common technique, the monitor may grow too large to be treated as a single module. 

Typically, this leads to multiple modules. In this case the mechanics of constructing the monitor are 
changed somewhat. There must be a central location that contains the monitor lock for the monitor 
implemented by the multiple modules. This can be done either by using a monitored record or 
by choosing one of the modules to be the "root" of the monitor. Consider the following example: 

BigMonRoot: monitor imports . . . exports . . . = 

BEGIN 

monitorDatuml: ... 
monitorDatuml: ... 

pi: public entry PROCEDURE .. . 
END. 

BigMonA: monitor 

LOCKS root -- could equivalently say roo/.LOCir 

imports root: BigMonRoot . . . exports . . . shares BigMonRoot = 

BEGIN 

p2: PUBLIC ENTRY PROCEDURE ... 

X <- root,monitorDatuml\ -- access the protected data of the monitor 

END. 

BigMonB: monitor 
LOOKS root 

imports root: BigMonRoot . . . EXPORTS . . . shares BigMonRoot = 
BEGIN OPEN root; 

pi: PUBLIC ENTRY PROCEDURE . . . 
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monitorDatunil <-...: - access the protected data via an open 

END. 

ITic monitor BigMon is implemented by three modules. The modules BigMonA and BigMonB have 
a LOCKS clause to specify the legation of the monitor lock: in this case, the distinguished variable 
LOCK in BigMofiRooL When any of the entry procedures pi, /;2, or p3 is called, this lock is 
acquired (waiting if necessary), and is released upon returning. The reader can verify that no two 
independent prcx:esses can be in the monitor at the same time. 

Note that since the LOCK field is private in BigMonRoou the modules BigMonA and BigMonB 
must SHARE BigMonRoot. Another way to accomplish access to the lock would be to specify a 
PUBLIC GlobalAccess (sec. 7.5) for BigMonRoot. 

Another means of implementing multi-module monitors is by means of a monitored record. Use 
of OPEN allows the fields of the record to be referenced without qualification. Such a monitor is 
written .as: 

MonitorData: type = monitored record [x: integer, . . . ]; 

MonA: monitor \pm: pointer to MonitorData] 

LOOKS pm 
imports ... 
exports . . . = 
begin open /?m; 

P\ ENTRY PROCEDURE [. . .] = 
BEGIN 

x^ xA-\\" access to a monitor variable 
end; 

END. 

The locks clause in the heading of this module (and each other module of this monitor) leads to a 
MONITORED RECORD. Of course, in all such multi-module monitors, the locks clause will involve 
one or more levels of indirection (pointer to monitored record, etc.) since passing a monitor lock 
by value is not meaningful. As usual. Mesa will provide one or more levels of automatic 
dereferencing as needed. 

More generally, the target of the locks clause can evaluate to a monitorlock (i.e. the example 
above is equivalent to writing "locks pm.IOCA^'). 

CAUTION: The meaning of the target expression of the locks clause must not change between the 
call to the entry procedure and the subsequent return (i.e. in the above example, changing pm would 
invariably be an error) since this would lead to a different monitor lock being released than was 
acquired, resuUing in total chaos. 

There are a few other issues regarding multi-module monitors which arise any time a tightly coupled 
piece of Mesa code must be split into multiple module instances and then spliced back together. For 
example: 

If the lock is in a monitored record, the monitor data will probably need to be in the 
record also. While the global variables of such a multi-module monitor are covered by the 
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monitor lock, they do not constitute monitor data in the nonnal sense of the term, since they 
are not unifonnly visible to all tlie module instances. 

Making the internal prcx:edures of a multi-module monitor private will not work if one 
module wishes to call an internal procedure in another module. (Such a call is perfectly 
acceptable so long as the caller already holds the monitor lock). Instead, a second interface 
(hidden from the clients) is needed as part of the "glue" holding the monitor together. Note 
however, that Mesa cannot currently check that the procedure being called tlirough the 
interface is an internal one (see section 10.2.4). 

A fine point: 

The compiler will complain about the PUBLIC INTERNAL procedures, but this is just a warning. 

10.4.5, Object monitors 

Some appUcations deal with objects, implemented, say, as records named by pointers. Often it is 
necessary to insure that operations on these objects are atomic, i.e., once the operation has begun, 
the object will not be otherwise referenced until the operation is finished. If a module instance 
provides operations on some class of objects, the simplest way of guaranteeing such atomicity is to 
make the module instance a monitor. This is logically correct, but if a high degree of concurrency is 
expected, it may create a bottleneck: it will serialize the operations on all objects in the class, radier 
than on each of them individually. If this problem is deemed serious, it can be solved by 
implementing the objects as monitored records, thus effectively creating a separate monitor for each 
object. A single module instance can implement the operations on all the objects as entry 
procedures, each taking as a parameter the object to be locked. The locking of the parameter is 
specified in the module heading via a LocksCiause with a using clause. For example: 

ObjectRecord: type = monitored record [...]; 

ObjectHandle: type = pointer to ObjectRecord: 

ObjectManager. monitor [arguments] 

LOCKS object USING object: ObjectHandle 
IMPORTS . . . 
exports . . . = 

BEGIN 

Operation: public entry procedure [object: ObjectHandle, . . . ] = 

BEGIN 

end; 

END. 

Note that the argument of using is evaluated in the scope of the arguments to the entry procedures, 
rather than the global scope of the module. In order for diis to make sense, each entry procedure, 
and each internal procedure that does a wait, must have an argument which matches exactly the 
name and type specified in the using subclause. All other components of the argument of locks 
are evaluated in the global scope, as usual. 

As with the simpler form of locks clause, the target may be a more complicated expression and/or 
may evaluate to a monitor lock rather than a monitored record. For example: 

LOCKS p. q. LOCK USING p: pointer to ComplexRecord ... 
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CAUTION: Again, the meaning of the target expression of the locks clause must not change between 
tlie call to the entry procedure and the subsequent return. (I.e. in the above example, changing p or 
p.q would almost surely be an error.) 

CAUTION: It is important to note that global variables of object monitors are very dangerous: they 
are not covered by a monitor lock, and thus do not constitute monitor data. If used at all, they must 
be set only at module initialization time and must be read-only thereafter. 

10J,6, Explicit declaration of monitor locks 

It is possible to declare monitor locks explicitly: 

myLock: monitorlock; 

The normal cases of monitors and monitored records are essentially stylized uses of this facility via 
the automatic declaration of LOCK, and should cover all but the most obscure situations. For 
example, explicit delarations are useful in defining machine dependent monitored records. (Note 
that the locks clause becomes mandatory when an explicitly declared monitor lock is used.) More 
generally, explicit declarations allow the programmer to declare records with several monitor locks, 
declare locks in local frames, and so on; this flexibility can lead to a wide variety of subtle bugs, 
hence use of the standard constructs whenever possible is strongly advised. 

10 J J Inline entry procedures 

The syntax for definitions modules allows the specification of a locks clause. This is to allow inline 
ENTRY PROCEDURES to be declared in the interface. In order for this to make sense, the monitor 
lock must be an interface variable, or the procedures must deal with an object style monitor. No 
special restrictions (other than those that apply to all inline bodies) need be met when declaring 
inline entry procedures within the program module of a monitor. 

10.5. Signals 

10,5. L Signals and processes 

Each process has its own call stack, down which signals propagate. If the signaller scans to the 
bottom of the stack and finds no catch phrase, the signal is propagated to the debugger. The 
important point to note is that forking to a procedure is different from calling it, in that the forking 
creates a gap across which signals cannot propagate. This implies that in practice, one cannot 
casually fork to any arbitrary procedure. The only suitable targets for forks are procedures which 
catch any signals they incur, and which never generate any signals of their own.' 

70.5.2. Signals and monitors 

Signals require special attention within the body of an entry procedure. A signal raised with the 
monitor lock held will propagate witiiout releasing the lock and possibly invoke arbitrary 
computations. For errors, this can be avoided by using the return with error construct. 

RETURN WITH ERROR N oSuchObject\ 

Recall from Chapter 8 that this statement has the effect of removing the currentiy executing, frame 
from the call chain before issuing the error. If the statement appears within an entry procedure. 
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the monitor lock is released before the error is started as well. Naturally, the monitor invariant must 
be restored before tiiis operation is performed. 

For example, consider tlie following program segment: 
Failure: ERROR [kind: cardinal] = CODE; 

Proc: ENTRY PROCEDURE [. . .] RETURNS [cl, c2: CHARACTER] = 
BEGIN 
ENABLE UNWIND => . . . 

IF condJ THEN ERROR Failur^l]\ 

IF cond2 THEN RETURN WITH ERROR Failur^l]: 

end; 

Execution of the construct error Failur^l] raises a signal that propagates until some catch phrase 
specifies an exit. At that time, unwinding begins; the catch phrase for unwind in Proc is executed 
and then Proc's frame is destroyed. Within an entry procedure such as Proc, the lock is held until 
the unwind (and thus through unpredictable computation performed by catch phrases). 

Execution of the construct return with error Failur^l] releases the monitor lock and destroys the 
frame of Proc before propagation of the signal begins. Note that the argument list in this construct 
is determined by the declaration of Failure (not by Proc\ returns clause). The catch phrase for 
unwind is not executed in this case. The signal Failure is actually raised by the system, after which 
Failure propagates as an ordinary error (beginning with Proc\ caller). 

When the return with error construct is used from within an internal procedure, the monitor lock 
is not released; return with error will release the monitor lock in precisely, those cases that 
return will. 

Anodier important issue regarding signals is the handling of unwinds; any entry procedure that may 
experience an unwind must catch it and clean up the monitor data (restore the monitor invariant): 

P: entry procedure [...] = 

begin enable unwind => begin <restore invariant> end; 



end; 

At the end of the unwind catchphrase, the compiler will append code to release the monitor lock 
before the frame is unwound. It is important to note that a monitor always has at least one cleanup 
task to perform when catching an unwind signal: the monitor lock must be released. To this end, the 
programmer should be sure to place an enable-clause on the body of every entry procedure that 
might evoke an unwind (directly or indirectly). If the monitor invariant is already satisfied, no 
further cleanup need be specified, but the null catch-phrase must be written so that the compiler will 
generate the code to unlock the monitor: 

begin enable unwind => null; 

This should be omitted only when it is certain that no unwinds can occur. 

Another point is that signals caught by the OptCatchPhrase of a wait operation should be 
thought of as occurring after reacquisition of the monitor lock. Thus, like all other monitor code. 
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catch phrases within a monitor are always executed with the monitor lock held. 

10.6. Initiah'zation 

When a new monitor comes into existence, its monitor data will generally need to be set to some 
appropriate initial values; in particular, the monitor lock and any condition variables must be 
initialized. As usual Mesa takes responsibility for initializing the simple common cases; for the cases 
not handled automatically, it is tlie responsibility of the programmer to provide appropriate 
initialization code, and to arrange that it be executed at the proper time. The two types of 
initialization apply in the following situations: 

Monitor data in global variables can be initialized using the normal Mesa initial value 
constructs in declarations. Monitor locks and condition variables in the global frame will 
also be initialized automatically (although in this case, the programmer does not write any 
explicit initial value in the declaration). 

Monitor data in records must be initialized by the programmer. System procedures must be 
used to initialize the monitor lock and condition variables. See the runtime documentation 
for the descriptions of appropriate procedures. 

A fine point: 

If a variable containing a record is declared in a frame, it is normally possible to initialize it in the 
declaration (i.e. using a constructor as the initial value); however, this does not apply if the record 
contains monitor locks or condition variables, which must be initialized via calls to system procedures. 

Since initialization code modifies the monitor data, it must have exclusive access to it. The 
programmer should insure this by arranging that the monitor not be called by its client processes 
until it is ready for use. 
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APPENDIX A. Pronouncing Mesa 

Tlie following suggestions may be helpful in reading Mesa programs: 



For 




Read 




= > 




chooses 




♦- 




gets 




n: T 




n is a r 




ntfield 




m\ field 




Pt 




ps referent 




@x 




address of x 




[a..b] 




(the interval) 


a through b 


[a..b) 




(the interval) 


a up to b 


ia.b] 




(the interval) 


above a through b 


ia.b) 




(the interval) 


above a up to b 


FOR / ♦■ 


• j. k ... 


for / getting 


first j\ thereafter k 


f[x, y. 


4 


/of X, y and z 


! 




enabling 





We leave as an exercise for the reader the following statement, attributed to Oscar Hammerstein II. 
/ *■ weary and Sick[trying]; 
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APPENDIX B. Programming Conventions 

The Mesa compiler only uses blanks, tabs, and carriage returns as separators for basic lexical units 
such as identifiers; extra ones do not hurt. Furthermore, it allows you to write identifiers in any 
combination of upper and lower case letters: the identifiers Alpha, ALPHA, alpha and AlphA are 
all legal (but different) Mesa identifiers. It is recommended that you adhere to a standard set of 
conventions for constructing identifiers and laying out programs. The recQmmended conventions are 
summarized below. 

B,L Names 

Most identifiers should be written in lower case, except that the first letter of each new "word" in 
the identifier should be capitalized. Thus, 

line 

firstLine 

firstLinePos 

This convention makes it easy to read identifiers which are made up of several words. (Note that 
Mesa does not allow spaces in identifiers.) 

Capitalize the first letter of type identifiers, procedure names, signal names, and module names. 

The following cx)nvention for constructing names has been used successfully to reflect their types: 

Choose a short (2-3 character) tag for each "basic type" you use: e.g.. In for Line and co for Coordinate. You 
can use the tag as the type name, or not. as you prefer. If you do, capitalize it 

Use the following prefixes to construct tags for "derived" types (most of them reflect the intended use of some 
underlying type). 

p - pointer: pLn = pointer to a line 

i - index: iLn = index in an array of lines. 

1 - length 

n - number of items (total or count) 

Whether to use a prefix or to invent a new type tag, is a matter of judgment: depending on whether it is 
better to emphasize the relationship of this type to another, or to emphasize its individuality. 

If you need only one name of a given type in a scope, use the tag as its name: 

In : Ln: 

pLn : POINTER TO Ln. 

If you need several names, append modifiers to the tag (avoid simple numbers like 1, 2, etc.): 

InOld, InNew, InBuffer: Ln. 
The advantages of this scheme are three-fold: 

the reader spends less time looking up the types of identifiers: 

the writer spends less time thinking up names: 

if you have forgotten a name, there is a good chance you will be able to guess it correctly if you 
know the tag vocabular\'. 

B.2. Layout 

Write statements one per line, unless several simple statements which together perform a single 
function will fit on one line. 

Indent the labels of a select (including the endcase) one level, and the statements a second level 
(unless a statement will fit on the same line with the label). 
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Indent one level for the statement following a then or else (unless it fits on the same line). Put 
THEN on tlie same line with if, and don't indent else with respect to if. If the statement following 
ELSE is another if, write botli on the same line. 

Indent one level for each compound begin-end, do-endloop, or bracket pair in a record declaration. 

When the rules for if and select call for indenting a statement, do not indent an extra level for a 
begin. 

It is fine to put a compound statement or loop on a single line if it will fit. 

If a statement won't fit on a single line, indent the continuation line(s) by two spaces. 

Among other things, these rules have the property that they allow a program to be easily converted 
to a form in which the bracketing is implied by die indentation. 

B.3, Spaces 

The following rules for spaces should be broken when necessary, but are a good general guide: 
A space after a comma, semicolon, or colon, and none before 
No spaces inside brackets or parentheses 
No spaces around single-character operations: *, -, etc., except for *-. 
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APPENDIX C Alto/Mesa Machine Dependencies 

This appendix contains a number of machine-dependent constants and definitions for the Alto 
implementation of Mesa. 

C/. Numeric limits 

On the Alto, the numeric limits are the following: 

first[integer] = -32768 = -2^^ and has internal representation lOOOOOB 
last[integer] = 32767 = 2^^-1 and has internal representation 077777B 
last[cardinal] = 65535 = 2-^^-1 and has internal representation 177777B 
first[long INTEGER] = -2147483648 = -2^^ 
LAST[L0NG INTEGER] =2147483647 =2^-^-1 
last[long CARDINAL] =4294967295 =2^^-l 

C.2 AhoDefs 

A module similar to the one below is a part of die Alto/Mesa system and defines several useful 
constants. 

AltoDefs: DEFINITIONS = 
BEGIN 

wordlength: INTEGER = 16; - Alto word length (bits) 

maxword: CARDINAL = 177777B; -- N.B. negative as 16 bit integer 

maxinteger: INTEGER = 077777B; - maximum positive number 

charlength: INTEGER = 8; -- Alto character size (bits) 

maxcharcode: INTEGER = 377B; 

BYTE: TYPE = [0../T7axc/?a/'eoc/e]; 

BytesPerWord, CharsPerWord: INTEGER = wordlength /charlength; 

LogBytesPerWord, LogCharsPerWord: INTEGER = 1; 

PageSize: INTEGER = 266; -- Alto page size (words) 

LogPageSize: INTEGER = 8; 

BytesPerPage, CharsPerPage: INTEGER = PageSize*CharsPerWord\ 

LogBytesPerPage, LogCharsPerPage: INTEGER = LogPageSize -i- LogCharsPerWord; 

VMLimIt: CARDINAL = 177777B; -- maximum Alto VM address 
Address: TYPE = [O..VMLimit]; 

MaxVMPage: INTEGER = 255; - maximum Alto VM page number 
MaxFilePage: CARDINAL = 077777B; 

PageN umber: TYPE =; [O..A/f axF/7ePage]; 
PageCount: TYPE = lO..MaxVMPage + ^]; 

END. 
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CJ, ASCII character set and ordering of character values 

^rhe following list gives the characters of the ASCII character set in increasing order, accompanied 
by their literal representations. Control characters are represented as ta. In addition, a number of 
special characters such as SP (space), DEL (rubout) are denoted by their generally accepted names. 



Octal Character 


Value Na 


me(s) 


OOOC NUL 


OOIC 


rA 


002C 


rB 


003C 


tC 


004C 


rD 


005C 


rE 


006C 


rP 


007C 


fG, BELL 


OlOC 


tH. BS 


one 


tl 


012C 


tj, LF 


013C 


fK 


014C 


fL 


015C 


tM, CR 


016C 


tN 


017C 


to 


OlOC 


rP 


021C 


^Q 


022C 


tR 


023C 


tS 


024C 


rT 


025C 


rU 


026C 


fV 


027C 


tW 


030C 


fX 


031C 


rY 


032C 


fZ 


033C ESC 


034C 




035C 




036C 




037C 




040C 


;SPace 


041C 


1 


042C 


•1 


043C 


# 


044C 


s 


045C 


% 


046C 


& 


047C 


', a single quote 


050C 


( 


051C 


) 


052C 


* 


053C 


+ 


054C 




055C 


'— 


056C 




057C 


/ 


060C 





061C 


1 


062C 


2 


063C 


3 


064C 


4 


065C 


5 


066C 


6 


067C 


7 


070C 


8 


071C 


9 


072C 




073C 




074C 


< 


075C 


zz 


076C 


> 


077C 


7 



Octal 


Character 


Value 


Name(s) 


lOOC 


'@ 


lOlC 


A 


102C 


*B 


103C 


C 


104C 


D 


105C 


E 


106C 


T 


107C 


G 


HOC 


H 


lllC 


'I 


112C 


J 


113C 


'K 


114C 


'L 


115C 


M 


116C 


'N 


117C 





120C 


'P 


121C 


Q 


122C 


'R 


123C 


'S 


124C 


T 


125C 


'U 


126C 


V 


127C 


W 


DOC 


X 


131C 


T 


132C 


Z 


133C 


\ 


134C 


135C 


1 


136C 


't 


137C 


V 


140C 




141C 


'a 


142C 


'b 


143C 


'c 


144C 


'd 


145C 


'e 


146C 


T 


147C 


'g 


150C 


'h 


151C 


'i 


152C 


'j 


153C 


'k 


154C 


'1 


155C 


'm 


156C 


'n 


157C 


'o 


160C 


'p 


161C 


'q 


162C 


'r 


163C 


's 


164C 


't 


165C 


'u 


166C 


'v 


167C 


'w 


170C 


'x 


171C 


'y 


172C 


'z 


173C 


'{ 


174C 


] 


175C 


176C 




177C 


DEL 
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C,4, Alto/Mesa string procedures 

A module similar to the one below is a part of the Alto/Mesa system and defines useful procedures 
provided by the system for operating on strings. See the system documentation for its exact form. 

DIRECTORY AltoDefs: FROM "altodefs"; 

StringDefS: DEFINITIONS = 
BEGIN 

--COMPILE-TIME CONSTANTS AND TYPES 

SubStringDescriptor: TYPE = RECORD [ 
/>ase; STRING, 
offset length: CARD\HAL]; 

Substring: TYPE = POINTER TO SubStringDescripton 

-INTERFACE ITEMS 

Ov^erf/ow; SIGNAL; 

InvaridNumber: S\GHAL; 

StringBoundsFault: SIGNAL [s; STRING] RETURNS [ns: STRING]; 

WordsForString: PROCEDURE [nchars: CARDINAL] RETURNS [CARDINAL]; 

AppendChan PROCEDURE [s: STRING, C; CHARACTER]; 

AppendString: PROCEDURE [tojrom: STRING]; 

EqualString, EqualStrings: PROCEDURE [sh $2: STRING] RETURNS [BOOLEAN]; 

EquivalentString, EquivalentStrings: PROCEDURE [$1, $2: STRING] RETURNS [BOOLEAN]; 

AppendSubString: PROCEDURE[fo; STRING, from: Substring]; 

EqualSubString, EqualSubStrings: PROCEDURE [s7, s2: Substring] RETURNS [BOOLEAN]; 

EquivaientSubString, EquivalentSubStrings: PROCEDURE [st s2: Substring] RETURNS [BOOLEAN]; 

DeleteSubString: PROCEDURE {$: Substring]', 

Uppercase. LowerCase: PROCEDURE [CHARACTER] RETURNS [CHARACTER]; 

StringToDecimal: PROCEDURE [STRING] RETURNS [INTEGER]; 

StringToOctal: PROCEDURE [STRING] RETURNS [UNSPECIFIED]; 

StringToNumber: PROCEDURE [si STRING, radix: CARDINAL] RETURNS [UNSPECIFIED]; 

StringToLongNumber: PROCEDURE [si STRING, rad/x: CARDINAL] RETURNS [LONG UNSPECIFIED]; 

AppendDecimal: PROCEDURE [s! STRING, n: INTEGER]; 

AppendOctah PROCEDURE [s: STRING, n: UNSPECIFIED]; 

AppendNumber: PROCEDURE [s: STRING, n: UNSPECIFIED, radix: CARDINAL]; 

AppendLongDecimal: PROCEDURE [s: STRING, n: LONG INTEGER]; 

AppendLongNumber: PROCEDURE [s : STRING, n: LONG UNSPECIFIED, radix: CARDINAL]; 

END. 



175 



APPFNDFX I). Binder Extensions 

The Alto implementation of the Mesa binder provides two extensions for controlling the space 
occupied by Mesa programs at runtime. These are specified with tlie CPacking and CLinks 
clauses (section 7.7). 

D.L Code packing 

It is possible to pack together the code for several modules into a single segment, ^rhis is useful for 
two reasons: 

Since the code is allocated an integral number of pages, there is some wasted space in the 
last page ("breakage"). If several modules are combined into a single segment, the breakage 
is amortized over all the modules, and there is less waste on the average. 

All the modules will be brought into and out of memory together, as a unit; a reference to 
any module in the pack will cause all the code to be brought in. Modules which are tightly 
coupled dynamically are good candidates for packing (for example, resident code should 
probably always be packed). 

Of course, it is possible to "over pack" a configuration; the segments might become so large that 
there will never be room in memory for more than one of them at a time (this should remind you of 
an overlay system). Packing is a tradeoff, and should be used with caution, 

D,LL Syntax 

The segments are specified at the beginning of the configuration by giving a list of the modules 
which comprise each one. Any number of pack statements may appear. The scope of the packing 
specification is the whole configuration, and not subconfigurations or individual module instances, 
because there is at most one copy of a module's code in any configuration. 

ConfigDescription 

::= Directory CPacking Configuration . 

::= empty jCPackSeries ; 

= PACK IdList 

= CPackList | CPackSeries ; CPackList 



CPacking 

CPackList 

CPackSeries 



Each PackList defines a single segment; the code for all the modules in the IdList will be packed 
into it. The identifiers in the IdList must refer to modules in the configuration, and not to module 
instances: it is the code and not the global frames that are being packed (the frames are always 
packed when they are allocated by the loader). 

It is illegal to specify the same module in more than one PackList. Even though there may be 
multiple instances of the module (i.e., multiple global frames) in the configuration, the code is 
shared by all of them, and therefore can only appear in one pack. 

Finally, it is perfectly fine to reach inside a previously bound configuration that is being instantiated 
and single out some or all of its modules for packing. Of course, you must know something about 
die structure of that configuration in order to do this. 
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DJ.2. Reslriciiom 

Obviously, the pack statements apply only if the code is being moved to the output file; otherwise, 
the pack lists are ignored (and no warning message is given). I^his allows the programmer to debug 
the configuration without shuffling the code from file to file, thereby saving time. When making the 
final N'ersion, the packing can be effected with a binder switch, without having to modify the source 
of tlie configuration description. 

Once some modules have been packed together, they cannot be taken apart and repacked w idi other 
modules later on, when they are bound into some other configuration. 

Fine point: 

If a previously bound configuration contains a pack, referencing any module of the pack gets the whole thing. 
So it is possible to pack a module and a pack together, or even to pack two packs. It is never possible to 
unpack a pack. 

In general, code packing should be specified only to the extent that no unpacking will ever "be 
desired. Once the packing is done, it can't be undone, unless you start over with the individual 
modules. 

/).2 External links 

In previous Mesa systems, links to the externals referenced by a program (imported procedures, 
signals, errors, frames, and programs) were always stored in the module's global frame. This allows 
each instance of a module to be bound differently, and it allows binding to be done at runtime 
without modification of the module's code segment. However, it has two drawbacks: 

The links are only referenced by the module's code, and are therefore not needed when the 
code is swapped out. Hence, the links logically belong in the code segment. 

If two instances of a module are bound identically (the usual case), the links must be stored 
twice. 

Fine Point: 

To determine the amount of space required for external links, see the compiler's typescript file. Each 
link occupies one word. 

The Mesa binder optionally places links in the code segment. This option is enabled by constructs 
in the configuration language, and is further controlled by binder and loader switches. 

DJ,L Syntax 

For each component of a configuration, the link location is specified using the links construct 
defined below. The default is frame links. 

CLinks :: = empty | links : code | links : frame 

A link specification can optionally be attached to each instantiation of a module, overriding the 
current default, so that the link location can be different for each^ instance. 

CRightSide :: = item | Item [ ] CLinks | Item [ IdLlst ] CLinks 
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Alternately, the link option can be specified in the configuration header. This merely changes the 
default option for the configuration; it will apply to all components (including nested configurations) 
unless it is explicitly overridden. 

CHead :: = configuration Clinks Imports CExports ControlClause 

Iliis constmction works much like the public / private options in Mesa, and it nests in the same 
way. A link option attached to a configuration changes the default for all components witliin it, but 
that default can be overriden for a particular module (or nested configuration) by specifying a 
different link option. 

D.2,2. Restrictions 

This scheme has the consequence that, // a module with code links has multiple instances, each 
instance must be bound the same. 

As with code packing, the code links option takes effect only when the code is being moved to the 
output file. At this point, the binder will make room for the links as it copies the code if any 
module sharing that code has requested code links. Again, this allows a programmer to debug 
without the expense of moving the code (using frame links), and then to effect the code links option 
widi a binder switch, without changing the source of the configuration description. 

Fine point: 

Once space for code links has been added to a configuration, it cannot be undone by a later binding. On the 
other hand, space for code links can always be added to a (previously bound) configuration, even if it did not 
specify code links in its description. 

Using code links has one drawback: it slows down the binding and loading process, as the code must 
be swapped in and rewritten. The binder must make room in the code segment for the links, as 
described above. And because the loader resolves imports of previously loaded modules, as well as 
the imports of the module being loaded, it may have to swap in (and perhaps update and swapout) 
the code segment for every module in the system. 

Because of the overhead involved, the loader will not automatically attempt lo use code links, even if 
the space is available in the code segment. A loader switch must be used to effect this option. 

Documentation of binder and loader switches in in the Mesa User's Handbook, 
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APPENDIX E. Mesa Reserved Words 

Listed below arc all of the Mesa reserved words. Words marked with an astrisk are predeclared 
rather than resetyed. Predeclared identifiers can be redefined (but seldom should be). 



ABS 

ALL 

AND 

ANY 

ARRAY 

BASE 

BEGIN 

BOOLEAN 

BROADCAST 

CARDINAL 

CHARACTER 

CODE 

COMPUTED 

CONDITION* 

CONTINUE 

DECREASING 

DEFINITIONS 

DEPENDENT 

DESCRIPTOR 

DIRECTORY 

DO 

ELSE 

ENABLE 

END 

ENDCASE 

ENDLOOP 

ENTRY 

ERROR 

EXIT 

EXITS 

EXPORTS 

FALSE* 

FINISHED 

FIRST 

FOR 

FORK 

FRAME 

FROM 

GO 

GOTO 

IF 

IMPORTS 

IN 

INLINE 

INTEGER 

INTERNAL 

JOIN 

LAST 

LENGTH 

LOCKS 

LONG 

LOOP 

LOOPHOLE 

MACHINE 

MAX 

MIN 



MOD 

MONITOR 

MONITORED 

MONITORLOCK* 

NEW 

NIL* 

NOT 

NOTIFY 

NULL 

OF 

OPEN 

OR 

ORDERED 

OVERLAID 

PACKED 

POINTER 

PORT 

PRIVATE 

PROCEDURE 

PROCESS 

PROGRAM 

PUBLIC 

READONLY 

REAL* 

RECORD 

RELATIVE 

REPEAT 

RESTART 

RESUME 

RETRY 

RETURN 

RETURNS 

SELECT 

SHARES 

SIGNAL 

SIZE 

START 

STATE 

STOP 

STRING 

StrtngBody* 

THEN 

THROUGH 

TO 

TRANSFER 

TRUE* 

TYPE 

UNSPECIFIED* 

UNTIL 

UNWIND* 

USING 

WAIT 

WHILE 

WITH 

WORD* 
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APPENDIX F. Collected Grammar 

llic Mesa grammar in this section is a collected version of the grammar distributed throughout the 
body of the Manual. There are some differences, primarily due to the Manual's grammar being 
distorted for purposes of exposition. This one is intended to be internally consistent. 

Hie grammar is divided into four parts, corresponding to the syntax for CompilationUnit, 
TypeSpeclfication, Statement, and Expression. These four parts refer to each other and 
occasionally use syntax mles from odier parts (such as LeftSide, which is used in an assignment 
statement but defined under Expression). Where such cross references occur, a comment has been 
added to indicate which part to refer to. Other than this, each part is self-contained, and the 
productions within a part have been ordered alphabetically by their names, except that the 
productions for CompilationUnit, TypeSpecification, etc. head their respective sections. 



CompilationUnit :: = 



Directory 

ExportsList 

FileName 

GiobalAccess 

idList 

ImportsList 

IncludeList 

interfaceitem 
interfaceList 
ModuleBody 
ModuleHead 

ModuieParams 

ShareList 

UsingCiause 



Directory 

identifier : ModuleHead = GiobalAccess 

ModuleBody 

empty | DIRECTORY IncludeList ; 

empty | EXPORTS IdList 

stringLiteral 

Access -- in TypeSpecification 

identifier | IdList , identifier 

empty | IMPORTS InterfaceList 

identifier : FROM FileName UsingCiause | 

IncludeList , identifier : FROM FileName UsingCiause 

identifier | identifier : identifier 

Interfaceitem | InterfaceList , Interfaceitem 

Block . - in Statement 

ProgramTC ImportsList ExportsList ShareList | 
DefinitionTC ImportsList ShareList 

empty | [ NamedFleldList ] -- In TypeSpecification 

empty I SHARES IdList 

empty I USING [IdList] 



TypeSpecification :: = 

PredefinedType | 
Typeldentlfier | 
TypeConstructor 

empty I PUBLIC I PRIVATE 

identifier 

PackingOption ARRAY IndexType OF TypeSpecification 

empty | BASE 

Expression I ByteList , Expression 

empty | NamedFleldList , 

Expression I ConstantList , Expression 

empty | ^ Def aultSpeciflcation 

empty | 
Expression] 
NULL I 
Expression I NULL 

DEFINITIONS | 
DEFINITIONS LocksClause 



Access 

Adjective 

ArrayTC 

BaseOption 

ByteList 

CommonPart 

ConstantList 

DefaultOption 

Def aultSpeciflcation 



DefinitionTC 
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Appendix F: Collected Grammar 



DescriptorTC 

ElementType 

EnumerationTC 

FieldList 

IndexType 

InlineOption 

InstructionSeries 

Interval 



LocksClause :: 

LongTC :: 

MachineCode :: 
MachineDependent 
MonitoredOption :: 
NamedFieldList 

Optionalinterval 

Ordered 

PackingOption 

ParameterList 

PointerTail 

PolnterTC 
PortTC 

PredefinedType 



ProcedureBody 
ProcedureTC 
ProcessTC 
ProgramTC 

ReadOnlyOption 

RecordTC 

RelativeTC 

ReturnsClause 

SignalOrError 

SignalTC 

SubrangeTC 

Tag 

TagType 
TypeConstructor 

Typeldentifier 



DESCRIPTOR FOR ReadOnlyOption TypeSpeclfication I 

DESCRIPTOR FOR ReadOnlyOption PackingOption ARRAY OF TypeSpeclfication 

INTEGER I CARDINAL | CHARACTER [BOOLEAN | 
EnumerationTC I SubrangeTC 

{IdList} 

[ UnnamedFieldLlst ] j [ NamedFieldList ] 

ElementType | Typeldentifier 

empty 1 INLINE 

empty I ByteList I ByteLlst ; InstructionSeries 

[ Expression .. Expression ] I 

[ Expression .. Expression ) I 

( Expression .. Expression ] I 

( Expression .. Expression ) 

empty j 

LOCKS Expression I 

LOCKS Expression USING identifier : TypeSpecificatlon 

LONG TypeSpeclfication 

MACHINE CODE BEGIN InstructionSeries END -- not described in this manual 

empty j MACHINE DEPENDENT 

empty {MONITORED 

IdList : Access TypeSpeclfication DefaultOption | 

NamedFieldList , IdList : Access TypeSpeclfication DefaultOption 



I 



Interval 
ORDERED 
PACKED 
FieldList 



PointerTail 



empty 

empty 

empty 

empty 

empty j 

TO ReadOnlyOption TypeSpeclfication | 

TO FRAME [ identifier ] 

Ordered BaseOption POINTER Optionalinterval 

PORT ParameterList ReturnsClause I 
RESPONDING PORT ParameterList ReturnsClause 

INTEGER I CARDINAL | LONG INTEGER | 
REAL I BOOLEAN | CHARACTER | STRING j 
MONITORLOCK | CONDITION | 
UNSPECIFIED I WORD 

InlineOption Block - Block in Statement 

PROCEDURE ParameterList ReturnsClause 

PROCESS ReturnsClause 

PROGRAM ParameterList ReturnsClause | 

MONITOR ParameterList ReturnsClause LocksClause 

empty I READONLY 

MonitoredOption MachineDependent RECORD [ VariantFieldList ] 

Typeldentifier RELATIVE TypeSpeclfication | 
Typeldentifier RELATIVE LONG TypeSpeclfication 

empty | RETURNS FieldList 

SIGNAL I ERROR 

SignalOrError ParameterList ReturnsClause 

Interval j Typeldentifier Interval 

identifier : Access TagType j 
COMPUTED TagType I 
OVERLAID TagType 

TypeSpeclfication | * 

DescriptorTC | ArrayTC j EnumerationTC j LongTC | 
PolnterTC j PortTC | Procedu reTC | ProcessTC j 
RecordTC j RelativeTC | SignalTC | SubrangeTC 

identifier I 
identifier . identifier | 
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UnnamedFieldList 

Variant 

VariantFieldList 



VariantList 
VariantPart 



Adjective Typeldentifier 
TypeSpecification | 
UnnamedFieldList , TypeSpecification 

IdList = > [ VariantFieldList ] , | 
IdList =>NULL, 

CommonPart identifier : Access VariantPart | 

VariantPart I 

NamedFieldList | 

UnnamedFieldList | 

empty 

Variant I VariantList Variant 
SELECT Tag FROM 
VariantList 
ENDCASE 



Statement 



AdjectiveList 

Assignation 

AssignmentStmt 

Block 



Call 



Catch 
Catchltem 
CatchSeries 
ChoiceSeries 

CompoundStmt 



ConditionTest 
ContinueStmt 
Declaration 



DeclarationSeries 
Direction 
EiseClause 
EnableClause 



AssignmentStmt I Block I Call I 

ContinueStmt I ExitStmt | GotoStmt | If Stmt j 

JoinCall I LoopCloseStmt | - JoinCall in Expression 

LoopStmt I Notif y I NullStmt I 

ResumeStmt j RetryStmt j ReturnStmt j SelectStmt | 

SignalCall | StartCall | RestartStmt | 

StopStmt I WaitStmt 

Adjective | AdjectiveList , Adjective - in TypeSpecification 

FOR identifier *• Expression , Expression 

Leftside ^ RightSide I -- LeftSide, RightSlde in Expression 

Extractor ♦■RightSide 

BEGIN 

OpenClause 

EnableClause 

DeclarationSeries 

StatementSeries 

ExitsClause 

END 



Variable 
Variable 



"in Expression 
ComponentList ] | 



Variable [ ComponentList ! CatchSeries ] 
Variable 



- ComponentList in Expression 



! CatchSeries 

ExpressionList = > Statement 

Catch I ANY => Statement 

Catchltem I Catch ; CatchSeries 

AdjectiveList => Statement ; I 
ChoiceSeries AdjectiveList = > Statement ; 

BEGIN 
Body 

ExitsClause 
END 

empty | WHILE Expression | UNTIL Expression 

CONTINUE 

IdList : 

Access 

ReadOnlyOption EntryOption 

TypeSpecification 

Initialization;! 

IdList : Access TYPE = Access TypeSpecification ; 

empty I DeclarationSeries Declaration 

empty I DECREASING 

empty | ELSE Statement 

ENABLE Catchltem; I 

ENABLE BEGIN CatchSeries END ; I 



- ExpressionList in Expression 



-Access in TypeSpecification 

-- ReadOnlyOption in TypeSpecification 
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EntryOption 
ErrorCall 
ExitsClause 
Ex it Series 

ExitStmt 

Extractltem 

Extractor 

FinalStmtChaice 
FinishedExit 

GotoStmt 

IfStmt 

InitExpr 



initialization 
Iteration 
iterativeControl 
KeywordExtract 
Key wo rdExt ractList 

Label 

LabelList 

Leftltem 

LoopCloseStmt 

LoopControl 

LoopExits 

LoopExitsClause 

LoopRange 

LoopStmt 



NotifyStmt 

NullStmt 
OpenClause 
Open item 
OpenList 
OptCatchPhrase 
PositionalExt ractList 



Repetition 

RestartStmt 

ResumeStmt 

RetryStmt 
ReturnStmt 



ENABLE BEGIN CatchSe ries ; END ; | 
empty 

empty (ENTRY 

ERROR Call I ERROR 

empty | EXITS| EXITS ExitSerles| EXITS ExitSerles ; 

LabelList => Statement | 

ExitSeries ; LabelList => Statement 

EXIT 

empty I Leftside 

[ Keywo rdExt ractList ] | 
[ PositionalExt ractList ] 

empty I => Statement 

FINISHED => Statement I 
FINISHED = > Statement ; 

GOTO Label | GO TO Label 

IF Expression THEN Statement ElseCiause 

Expression | 

ProcedureBody | - in TypeSpecification 
MachineCode | -- in TypeSpecification 
[Expression ] | - for STRING initialization 
CODE -- for SIGNAL initialization 

empty | ^ InitExpr | = InitExpr 

FOR identifier Direction IN LoopRange 

empty | Repetition | Iteration | Assignation 

identifier : Extractltem 

KeywordExtract I 

KeywordExt ractList , KeywordExtract 

identifier 

Label | LabelList , Label 

Expression 

LOOP 

IterativeControl ConditionTest 

ExitSeries | ExitSeries ; | FinishedExit j ExitSeries ; FinishedExit 

empty | REPEAT LoopExits 

SubrangeTC j Typeldentifier | BOOLEAN | CHARACTER 

LoopControl 

DO 

OpenClause 

DeclarationSeries 

EnableClause 

StatementSeries 

LoopExitsClause 

ENDLOOP 

NOTIFY Variable I 
BROADCAST Variable 

NULL 

empty | OPEN OpenList ; 

Expression | identifier : Expression 

Openltem | OpenList , Openltem 

empty I [ ! CatchSeries ] 

Extractltem! 

PositionalExtractList , Extractltem 

THROUGH Subrange - In Expression 

RESTART Variable OptCatchPhrase - Variable in Expression 

RESUME! 

RESUME [ ComponentList ] - ComponentList in Expression 

RETRY 

RETURN! 
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SelectStmt 
Select 

SelectVa riant 

SignaiCail 

StartCall 

StatementSeries 

StmtCholceSeries :: = 



StopStmt 
Tagltem 
Test 
Test Li St 
WaitStmt 



RETURN [ ComponentList ] | - ComponentList in Expression 
RETURN WITH ERROR Call 

Select I SelectVariant 

SELECT Leftltem FROM 
StmtChoiceSeries 
ENDCASE FinalStmtChoice 

WITH Openltem SELECT Tagltem FROM 

ChoiceSerie§ 

ENDCASE FinalStmtChoice 

SIGNAL Call I ErrorCall 

START Call 

empty | Statement | 
Statement ; StatementSeries 

TestList = > Statement ; j 
StmtChoiceSeries TestList => Statement ; 

STOP OptCatchPh rase 

empty {Expression 

Expression | RelationTail -RelationTail in Expression 

Test I TestList , Test 

WAIT Variable OptCatchPhrase 



Expression 



AddingOp 

AssignmentExpr 

BuiitinCall 



ChoiceList 

Component 

ComponentList 

Conjunction 

Constructor 

Disjunction 

ExprChoiceList 



ExpressionList 

Factor 

ForkCall 

FunctionCall 

IfExpr 

IndexedAccess 

IndirectAccess 

JoinCail 

KeywordComponent :: = 

KeywordComponentList 



AssignmentExpr I Disjunction | ForkCall j IfExpr j 
JoinCail j NewExp r j SelectExp r | 
SignalCall | -SignaiCail in Statement 

StartCall -StartCall in Statement 

+ I - 

Leftside ♦• RightSide 

MIN [ ExpressionList ] j MAX [ ExpressionList ] j ABS [ Expression ] | 

LENGTH [ Expression ] j BASE [ Expression ] j 

TypeOp [TypeSpecification ] | 

DESCRIPTOR [ Expression ] | 

DESCRIPTOR [ Expression , Expression ] | 

DESCRIPTOR [ Expression , Expression , TypeSpecification ] 

AdjectiveList => Expression , I - AdjectiveList in Statement 

ChoiceList AdjectiveList => Expression , 

empty I Expression I NULL 

KeywordComponentList I PositionalComponentList 

Negation j Conjunction AND Negation 

OptionalTypeld [ ComponentList ] 

Conjunction I Disjunction OR Conjunction 

TestList = > Expression , j -- TestList in Statement 

ExprChoiceList TestList => Expression , 

Expression | ExpressionList , Expression 
— Primary I Primary 
FORK Call 

BuiltinCail j Call - Call in Statement 
IF Expression THEN Expression ELSE Expression 
( Expression ) [ Expression ] | Variable [ Expression ] 
( Expression ) 1 1 Variable t 
JOIN Call 

identifier : Component 
:: = Key wordComponent I 

KeywordComponentList , KeywordComponent 
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Leftside 



Literal 



MuitipiyingOp 

Negation 

NewExpr 

Not 

bptionailypeld 

PositionalComponentList 

Primary :: = 



Product 

QualiftedAccess 

Relation 

RelationalOp 

RelationTail 

RightSide 
SelectExpr 
SelectExprSimple : 

SelectExprVa riant 



Subrange 

Sum 

TypeOp 

Variable 



identifier I Call I - Callin Statement 
IndexedAccess I QualifiedAccess I Indirect Access I 
LOOPHOLE [ Expression ] I 
LOOPHOLE [ Expression , TypeSpecification ] 

numericLiteral| - all defined outside the grammar 

stringLiteral I 

characterLiteral 

*|/|MOD 

Relation I Not Relation 

NEW Variable OptCatchPhrase 

--I NOT 

empty jTypeldentifier - in TypeSpecification 

;: = Component | 

PositionalComponentList , Component 

Variable I Literal I ( Expression ) I FunctionCall I 

Constructor I ALL [ Expression ] I @ Leftside I identifier [ Expression ] 

Factor I Product MuitipiyingOp Factor 

( Expression ). identifier I Variable . identifier 

Sum I Sum RelationTail 

# I = |<|<= |>|>= 

RelationalOp Sum I Not RelationalOp Sum I 

IN SubRange | Not IN Subrange 

Expression 

SelectExprSimple) SeiectExprVariant 

SELECT Leftltem FROM - Leftltem in Statement 

ExprChoiceList 

ENDCASE=> Expression 

WITH Openltem SELECT Tagltem FROM - Openltem, Tagltem in Statement 

ChoiceList 

ENDCASE => Expression 

SubrangeTCI - in TypeSpecification 

Typeldentifier -- in TypeSpecification 

Product I Sum AddingOp Product 

SIZE I FIRST I LAST 

Leftside 
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In this index, bold face page numbers 
indicate where the primary, defining 
information can be found; plain page 
numbers designate further examples. 

! 137, 138, 140 

83 
9 
* 12, 94, 95 
-h 12 
12 

2,5,6 

34,104,106-7 
/ 12 
::= 2 

; 5-6,53,57,136,137 
= > 54,56,94,96,136,138,140 
@ 29,42,44,147 
D 125,130 
t 42 

5,17,63,76,130 
ABS 5,12 

Access 94,104,117-20 
activation 72, 137 
actual procedure 68, 74, 78 
actual tag 94,97,99 
AddingOperator 12 
adjective 96 
adjectives 92,97 
aggregate type 22 
aligned 29,42,69 
ALL 30 

AlternateName 60,98 
ANY 136,138-9 
argument 72, 72 
arguments 67, 144 
arguments buffered 150 
array 22,27-8 

constructor 28,30 

descriptor 85, 87 
ARRAY 27-8, 29 
Assignation 63,63 
assignment 6, 51 

expression 52 
AssignmentExpr 11,17 
AssignmentStmt 7, 51 
automatic dereferencing 44 
B 8 

balancing 45,47 
BASE 29, 41, 43-4, 86, 87, 88, 90-1 
base type 25 



BCD 103,123 

BEGIN 57, 136 

Binary Configuration Description 103, 123 

binding 101, 103, 123-4, 132 

blank 6 

block 57 

Block 57, 57, 73, 137, 140 

BNF 2 

BOOLEAN 7-8, 16, 22, 24, 53 

bound variant 97 

bound variant type 93, 95, 96 

bounds 64 

BROADCAST 159, 160-1 

BuildinCall 12, 12 

built-in type 7 

C 9 

C/Mesa 103, 120, 125 

call 67 

Call 12, 71, 137, 140 

CallStmt 71 

CARDINAL 7,7,10,22,26-7,49 

Catch 134,136,137-9 

catch phrase 136, 139, 150, 154 

CHARACTER 7, 9, 15, 22 

characterLiteral 9 

client 120 

module 123 
CODE 125,135,141 
coercion 46, 73 
colon 6 
comma 56, 94 
comment 5,6 
common part 92 
CommonPart 118 
compatible 70 
compilation order 110 
CompilationUnIt 104 
compile- time 84, 104, 105 

constant 18, 30, 53 
completely bound variant 100 
component 27, 31, 125 
component type 27 
components 97 
ComponentType 29 

COMPUTED 94, 100 

computed tag 93, 95, 97, 100 
CONDITION 155, 158, 161 
condition variable 155 
ConditionTest 62, 63 
configuration 123 
Configuration 125 

CONFIGURATION 125, 126 

Configuration Description 103, 123-4 
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configuration prototype 125 
conform 7, 10, 72 
conforming 69 
Conjunction 16 

CONNECT 146, 147,150 

constant 18 
constructed data type 20 
constructor 35,93 
Constructor 30,35 
CONTINUE 140,141,146,150 
CONTROL 103, 125 

control fault 149 

link 148 

transfer 148 

variable 64 
ControlVariable 63,63 
coroutine 144 
covering condition variable 160 
CR 6, 141 
D 8 

Debugger 136, 139 
declaration 68 
Declaration 19 
DeclarationSeries 57 

DECREASING 63-4 

default Access 120 

default field 112 

default field values 36 

default-named interfaces 127-8 

DefaultOption 37 

DefaultSpecification 37 

defining occurance 108 

DEFINITIONS 78, 104, 105-6, 110, 117, 120 

definitions module 101 

DESCRIPTOR 29,85-6,87,91 

detached process 154 

determination of representation 49 

Digit 2 

DIRECTORY 78, 104-5, 106, 126 

discrimination 98, 100 

Disjunction 11, 16 

DO 5, 62, 136 

element type 22 

ElementType 22, 25 

elided 30 

elided component 35 

elides 36 

ELSE 5,52,76 

empty 3, 30 

empty 

constructor 72 

extractor 39 

interval 16, 29 



ENABLE 137,138,140-1 
EnableCfause 57 

END 57,76 

ENDCASE 54,56,77,94,99 
ENDLOOP 5,62,64 
ENTRY 155, 156 

entry procedure 155 
enumerated type 22 
enumeration 21, 94 
equality 6 
equivalent 10 
ERROR 135, 136, 141, 149 
ERROR, unnamed 136 
ErrorCall 135 
exceptional conditions 134 
EXIT ' 65, 66, 139, 141 
ExitsClause 57,57,137 
expansion 80 
explicit 

component 35 

naming 126-7 

qualification 109 
export 102,117,126 

record 102 
EXPORTS 78, 103-4, 117, 121, 124-5, 126, 

127 
Expression 11, 51 
ExpressionList 12 
external procedure 157 
extractor 38,128 
Extractor 51 
Factor 12 

FALSE 8,24 

FaultHandler 150, 151 
field list 32 
FieldDescription 118 
FieldList 31, 32 

FINISHED 65,66,141 

FIRST 24,26 

floating-point 10 

fonts 1 

FOR 63, 64 

forcible termination 65, 66 

FORK 136, 152-3, 153, 154 

formation rules 2 

frame 57, 148 

FRAME 104, 116, 125, 132, 146 

free conformance 48, 70 

FROM 104. 146 

FunctionCall 12 

fundamental operation 6, 20, 41, 69 

GCD 4 

GlobalAccess 117,120 
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GOTO 57, 58-9, 64, 66, 139 
home module 117 
identifier 21 

constant 23, 94 

list 6 
identifier 5, 127 
IdList 3.6 
IF 5.52,76 

expression 53 

statement 52 
IfStmt 52 
implementing 121 
implementor 120 
implicit qualification 99 
import 101 
imports 126 

IMPORTS 78/102-4, 115, 124-5, 126, 127 
IN 15,47,55,63 
include 105 
IncludeList 104 
indefinite index type 86 
index type 27 
indexed reference 27 
IndexedReference 29 
IndexType 29, 85 
inequality 6 
inherent 

representation 49 

type 45 
initialization 18, 68, 84, 135 
Initialization 19,33 
inline 69,73,80 
INLINE 80,113-4 
InlineOption 73 
instance 115, 124 
INTEGER 7,7,10,22,26-7,49 
interface 101, 120, 125, 135, 158 

element 110 

record 115, 116, 127 

type 115, 116 

variable 110, 111-2, 113-4 

INTERNAL 157, 165 

internal procedure 158 
interval 15, 63 
Interval 15 
Iteration 63,63 
IterativeControl 63 
JOIN 136, 152-3, 153, 154 
jump table 55 
keyword 39 

constructor 31, 35, 35, 74 

extractor 74 

name 35 
Label 58 



Labels 58 

LAST 24, 26 

Leftside 7,29,38,42,45,51 

length 82 

LENGTH 29, 86, 87 

lengthening 43 

lexical units 6 

link 124 

LinkageFault 148, 149, 150 

LINKS 125, 125 

literal 18 

Literal 12 

loader 132 

loading 123 

local string literal 84 

local variable 68 

LOCK 161 

LOCKS 162, 164, 166 

LocksClause 162, 165 

LONG 14,43,87,92 

CARDINAL 7,9-10 

INTEGER 7, 9-10 

POINTER 43 

STRING 85 

long numeric type 9 
LOOP 65, 139 
loop control 61 
loop statement 61 
LoopCloseStatement 65 
LoopControl 62 
LoopExitsClause 64 

LOOPHOLE 47 

LoopRange 63, 64 

lower bound 16 
lower-case 5 

MACHINE DEPENDENT 33, 94, 95, 166 
MACHINE DEPENDENT RECORD 29 
MAX 12,47 

maxlength 82, 83 

MIN 12, 47 

MOD 5 

module 61, 68, 101 

ModuieBody 104 

monitor 154, 155 

initialization 168 

lock 155 
MONITOR 156, 162 
MONITORED RECORD 162, 163*4 

MONITORLOCK 156, 162, 166 

Multi-module monitor 163 
multiple statements 6 
MultiplyingOperator 12 
name reference 108 
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name scope 34, 108 
NamedFieldList 32,118 
Negation 16 
nested configurations 130 

procedure 78 

signals 142 
NEW 116,131-2,136,146 
Next-Statement 51, 55, 62 
NIL 43,44,76 
non-interface 

element 110 

type 101 
non-local variable 68 
non-privileged 117 
NOTIFY 155, 157, 159, 160-1 
NULL 56,94 
number 8 
numeric 

literal 8 

operators 12 

type 7, 26 
object 

file 103 

module 101 
Object monitor 165 
objects 165 
OctalOigit 2 
omission 36 
OPEN 59,106,108-9 
open 

clause 98,107 

item 99 
OpenClause 57,61 
operator 12 

precedence 17 
ORDERED 41,43 
ordered type 22 
OVERLAID 94, 100, 148 
overlaid tag 95 
PACK 125 
packed 69 
PACKED 29, 85, 87 
parameter 67, 134 

record 67 
pending 147, 149-50 
phrase class 2 
PLUS 125, 130 
pointer 22, 39 

arithmetic 43 
POINTER 41, 43-4, 88 

POINTER TO FRAME 104, 116 

PORT 144-5, 146, 148, 151 
port-compatible 148 
PortFault 147, 149, 150 



positional constaictor 35, 36 
precedence 12, 52, 54 
PredefinedType 19 
Primary 12 
PRIVATE 104, 112-3, 117-20 
privileged 117 
procedure 67 

body 68 

calls 71 

descriptor 148 

type 69 

value 70, 148 

variable 74, 110 
PROCEDURE 69, 76, 148 
ProcedureBody 73 
process 166 
PROCESS 153,153 
Product 12 

PROGRAM 104, 115, 117, 120, 132, 145-6 
program 101 

prototype 116,125 

variable 116 
PUBLIC 76, 103-4, 113, 117, 117, 118-9, 121 
qualification 34,60,106 
qualified reference 31, 108 
qualifier 74 
Queue 156 
range 

assertion 27 

error 25 
readonly 40 

READONLY 41, 111 
REAL 7,10,10,46 

recompiling 109 
record 31 -^ 

constructor 31,35 

single-component 73 
RECORD 32,76,94,95 
recursive 72 

substitution 3 
reentrant 72 
reference type 39 
Reject 139 
relational operators 15 
RELATIVE 43,88,90-1 
relative 

array descriptor 89,91-2 

pointer 88, 89 
relocation 88 
REPEAT 64, 141 
Repetition 63 
reserved words 2, 5 

RESPONDING 145, 151 

RESTART 116, 132-3, 136, 146-7, 150 
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result 67, 135, 144 

record 73 
Resume 139 

RESUME 136, 136, 138. 140, 141 
ResumeError 141 
RETRY 140, 141 
RETURN 69, 72, 74, 132, 136, 148 
return link 138, 149 

RETURN WITH ERROR 135, 138, 139, 166-7 

RETURNS 69, 76 

RightSlde 7,51 

scalar type 22 

scale factor 8 

scope 74, 79, 99, 108, 137 

SELECT 54, 54, 56, 77, 93-6, 98, 99-100, 141, 

148 
SELECT expressions 56 
SelectExpr 56 
SeiectStmt 54 
self-contained 124 
Series 3 

SHARES 104, 117, 120 

short numeric type 9 
SIGNAL 59,135,136,141 
SignalCall 135 
Signaller 138,139,142,150 
signals 134 

actual 135 

catching 138 

nested 142 
signed number 7 
single-component record 73 
SIZE 34, 76 
SP 141 
space 6 
START 83, 116, 124, 132, 133, 136, 138, 144, 

146-7 
start trap 111, 133, 147 
startup transient 144, 147 
statement 51 
Statement 51 
StatementSe ries 57 
static variable 124 
StmtSerles 3 
STOP 124,132-3,136 
STRING 7, 82, 83 
string literal 83 
StringBody 82, 87 
strongly typed 4 
subrange 21 

type 22, 24 
Sum 12 
syntax notation 2 



TAB 6, 141 
tag 93 
Tag 118 
target 

representation 49 

type 45 
TC 21 
terminate 

conditionally 62 

forcibly 65 

normally 63 
text 82 
THEN 5, 52, 76, 125, 130 

THROUGH 63 

time Stamp 109 
timeout 161 
TRUE 8, 24 
TYPE 20, 21 
type 

constructor 7 

conversion 46 

determination 45 
type-correct 45 
TypeConstructor 21 
TypeDeclaration 20 
Typeldentifier 21,96,107 
TypeSpecification 21,90 
unbound variant 93 
unique type 91 
Unnamed FieldList 31 
unqualified 61 
unsigned number 7,43 
UNSPECIFIED 19,43 
UNTIL 5, 62, 140 
Unwind 139 

UNWIND 139, 140, 149-50, 167 
upper bound 16 
upper-case 5 
user-defined type 7 
USING 78,106,109,162,165-6 
Variable 12 
variant 

part 92,93,97,148 

record 92 
VariantFieldList 118 
VariantPart 118 
virtual interface record 102 
voided component 35 
voids 36 

WAIT 136, 155, 157, 159, 160-1, 166, 168 
WHILE 62 
WITH 98 

WORD 19 

XFER 148 
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